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

Faster gdb memory access #380

Merged
merged 2 commits into from May 13, 2023
Merged

Faster gdb memory access #380

merged 2 commits into from May 13, 2023

Conversation

xobs
Copy link
Member

@xobs xobs commented May 11, 2023

This improves GDB memory access times by coalescing 2-, 4-, and multi-byte reads and writes. This should improve access times considerably.

This is done through two methods:

  1. The TLB is no longer flushed on every byte read or written. The TLB is flushed only when performing a write to a page that was marked readonly, as is the case when patching a running program.
  2. Accesses are coalesced. Two-byte aligned accesses are now done in one operation, as are four-byte aligned accesses. Multi-byte reads that are aligned to four-bytes are batched as a sequence of four-byte reads.

This should improve memory access speeds considerably. Would you mind trying this on real hardware?

xobs added 2 commits May 11, 2023 15:11
Instead of remapping the page to allow the kernel to access a process'
memory, simply set the SUM bit. This makes it no longer an error for the
kernel to access userspace.

Keep setting the `W` bit when we poke, to allow for updating program
memory with breakpoints.

Signed-off-by: Sean Cross <sean@xobs.io>
Instead of always doing bytewise accesses, support 2- and 4-byte access.
Additionally, recognize when multiple 4-byte reads are required.

Note that an additional optimization may be made here in the future to
prevent having to check every address, but this is left for a future
optimization.

Signed-off-by: Sean Cross <sean@xobs.io>
@xobs xobs requested a review from bunnie May 11, 2023 07:18
@bunnie
Copy link
Member

bunnie commented May 12, 2023

It seems to be faster, and it's rock solid! Set a break point, stepped for 20-30 instructions....set the breakpoint again, called the server, saw the system break there, continued another few times, did register dumps, thread info, etc.

Great work!

@xobs
Copy link
Member Author

xobs commented May 13, 2023

Great! Was this with or without no-ack? I'm curious if this doesn't fix no-ack mode as well.

@bunnie
Copy link
Member

bunnie commented May 13, 2023

This is the command line I used to test:
riscv-none-elf-gdb -ex 'tar ext /dev/ttyS0' -ex 'attach 18' ~/trng

@bunnie bunnie deleted the faster-gdb-memory-access branch January 14, 2024 18:23
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

Successfully merging this pull request may close these issues.

None yet

2 participants