01-02-2020 11:57 AM
When the GDB client connects to hw_server, the bare metal processor stops. That is expected. What doesn't totally work is the GDB "detach" command. According to the GDB manual (https://sourceware.org/gdb/onlinedocs/gdb/Attach.html#index-detach):
When you have finished debugging the attached process, you can use the detach command to release it from GDB control. Detaching the process continues its execution.
Xilinx's implementation of GDB (in hw_server) does not obey that behavior. When I run "detach" in GDB, I see the GDB remote serial protocol "D" packet is sent to hw_server, and hw_server responds "OK". But the processor does not resume execution. I know the processor does not resume execution because I then connect with xsdb, run "targets", and see that the processor is still stopped.
I am testing on a Zynq MPSoC, and I see the same behavior for all processors: MicroBlaze, A53, and R5. So I think this is a bug in hw_server.
Is Xilinx aware of this bug? Is there a workaround? I really need a way to release the processor so it can go on about its business while I shutdown GDB.
01-02-2020 01:46 PM
Thanks for pointing out the issue, I will give a try and report internally to the development team.
From workaround point of view, does not behave similarly the target if you resume the execution manually as last statement prior closing the GDB session?
01-03-2020 06:27 AM
Hi @ibaie ,
Thanks for the reply!
The usual way to resume execution in GDB is the "continue" command. But that command blocks (i.e. you don't get another GDB prompt) until the target stops (usually by hitting a breakpoint). There is a command "continue&" with a "&" at the end that makes the target continue "in the background," but if you try to run the detach command while the target is executing in the background, GDB throws an error:
(gdb) continue& Continuing. (gdb) detach Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again.
You get the same error if you try the "disconnect" command.
The only "workaround" I have found is to do "continue&" and then close the whole terminal that GDB is running in. Not ideal, but it works for now.
Thanks for passing this along to the internal team!