GDB not working correctly? #215
Replies: 2 comments 1 reply
-
I've just tried this myself and see the same issue. Interestingly though, if you enable the breakpoint by removing the comment on the Can you try that out to see if you same the behaviour? If so that can serve as a workaround for now whilst I investigate the issue. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Ok, I found the problem. When the first breakpoint is hit after a number of tasks have been created, which occurs when You can verify this by reproducing the issue as you saw it but then issuing the command:
You can see that the task with the ID 5 (1.5 in the list above) is assumed to be the active thread. BTW, the text "(Running)" and "(Stopped)" comes from the stub itself and has no effect on the remote GDB apart from being reported in this list. If you issue the command below then you can continue debugging as normal and see the backtrace correctly:
The root cause was down to the order the tasks were reported from the GDB stub. When the remote GDB is initially connected, the first task list report must place the current task at the start of the list. This was not the case. I've created a PR to fix this: #216. |
Beta Was this translation helpful? Give feedback.
-
I am unable to resolve symbols in the back-trace in gdb and can't list code at current position.
Is it me/my setup or is the debugging functionality with the gdb-stub not working correctly at the moment?
Here is what I did on current main branch (4f312a3)
Run in Qemu as usual:
Connect gdb:
I checked a few commits from withing the last few weeks and they all behave the same.
I found a random commit where it still works: 649c638
I did not biscect this completely though.
Any hints welcome!
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions