Implement basic gdb server functionality. #52
Conversation
asanza
force-pushed
the
implement_gdb_server
branch
from
7715cb6 to
49ddf23
Compare
This commit introduces basic gdbserver support to the zmu ARM simulator, enabling remote debugging with a gdb client. The following features are implemented: * Breakpoints: Users can set, clear, and manage breakpoints during program execution. * Continue: Execution can be resumed from the current breakpoint or paused state. * Step Instruction: Users can step through program instructions for detailed debugging. This functionality significantly enhances the debugging capabilities of zmu, making it more versatile for developers. To start the gdbserver just call zmu with the --gdb flag: $ zmu.exe run --gdb binary.elf A gdb server will be open on localhost port 9001 Signed-off-by: Diego Asanza <[email protected]>
|
Which gdb version did you use on your testing? Start the emulator with gdb flag Run gdb: And got error from the zmu side: |
|
tested with arm-gnu-toolchain 14.2.Rel1 arm-none-eabi-gdb, seems to work for me! |
Thanks for your feedback! This is more like a proof of concept and also a way for me to learn Rust 😅. Ideally, I would like to have ZMU running in a separate thread and communicating with the GDB server through shared memory (or something similar). I actually tried implementing it that way, but I ran into problems with the Processor struct. Specifically, the itm_file and semihos_func references were causing issues because they depend on things that can’t be easily shared between threads. In my mind, the setup would involve the GDB server in one thread and the ZMU simulator in another. The GDB server could control ZMU using the step command and directly inspect the processor’s memory to check its status. However, I have to admit my Rust knowledge is still quite basic, so I’m not sure what the best approach would be for this. Right now, the GDB implementation isn’t very efficient, as it uses a polled TCP connection and waits 1ms in each step to check for incoming data. What do you think? Should we merge this as it is for now, or do you have any tips for how to approach the multithreading idea? I’d be happy to give it another try based on your suggestions. |
I think the right command is gdb-multiarch |
asanza
force-pushed
the
implement_gdb_server
branch
from
5039b76 to
4d8883a
Compare
Mostly comment fixes. Signed-off-by: Diego Asanza <[email protected]>
This whole project has been a hobby for learning rust, so no worries 👍
I think even this non-optimal version brings value to zmu development, I can see how it will be easier to implement new simulation features when there is well known UI for testing and inspecting things. So I would proceed to merge this non-optimal version. Maybe the doc/todo.md could be updated with a gdb heading that discusses the possibilities for the multi-threaded version. The shared memory approach would require wrapping stuff into Arc / Mutex, and with rust borrow checker sometimes that becomes quite tricky to manage overall. Another approach would be making a clear message-passing type API (eg using crossbeam). That could be used for semihosting, itm trace AND also controlling the simulator and reading processor information. Likely some experimentation is needed to find a good solution for this. |
This commit introduces basic gdbserver support to the zmu ARM simulator, enabling remote debugging with a gdb client.
The following features are implemented:
This functionality significantly enhances the debugging capabilities of zmu, making it more versatile for developers.
To start the gdbserver just call zmu with the --gdb flag:
$ zmu.exe run --gdb binary.elf
A gdb server will be open on localhost port 9001
