Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GDB Protocol is not handled correctly #630

Open
jounathaen opened this issue Jan 29, 2024 · 1 comment
Open

GDB Protocol is not handled correctly #630

jounathaen opened this issue Jan 29, 2024 · 1 comment

Comments

@jounathaen
Copy link
Member

When I run cargo test gdb on the main branch and add a print to the read_addrs function,

fn read_addrs(&mut self, start_addr: u64, data: &mut [u8]) -> TargetResult<usize, Self> {

I get the following reads:

[...]
>>>  reading start_addr 0x59d478
>>>  reading start_addr 0x64412074656e726d
>>>  reading start_addr 0x64412074656e7265
>>>  reading start_addr 0x64412074656e7265
>>>  reading start_addr 0x64412074656e726d
>>>  reading start_addr 0x3f8000
>>>  reading start_addr 0x0
>>>  reading start_addr 0x99d478
>>>  reading start_addr 0x99d478
>>>  reading start_addr 0x99d478
>>>  reading start_addr 0x649a84
[...]

0x64412074656e726d is definitely not a valid virtual address on x86.
Currently, this fails silently, as the virt_to_phys() maps this address to the address 26d.

-> We should check, whether this is valid memory and return an Error if not (read_addr API as reference: https://docs.rs/gdbstub/latest/gdbstub/target/ext/base/singlethread/trait.SingleThreadBase.html#tymethod.read_addrs)

@jounathaen
Copy link
Member Author

This is partly fixed in #527, where this access returns an error to gdbstub.
However, I'm still not sure why this address is accessed at all?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant