[RTEMS Project] #4739: Fatal errors running GDB testcase against libdebugger
RTEMS trac
trac at rtems.org
Wed Oct 12 08:42:31 UTC 2022
#4739: Fatal errors running GDB testcase against libdebugger
------------------------------+--------------------------
Reporter: Kévin Le Gouguec | Owner: Chris Johns
Type: defect | Status: new
Priority: normal | Milestone:
Component: lib/debugger | Version: 6
Severity: normal | Resolution:
Keywords: | Blocked By:
Blocking: |
------------------------------+--------------------------
Comment (by Kévin Le Gouguec):
Replying to [comment:3 Chris Johns]:
> I can add a feature to `libdebugger` to have it wait but I am not sure
what happens once connected? Do I break and wait for the user via GDB or
continue or should this be optional?
Thanks for weighing in on this! Yes, I think it would make sense to have
an option to wait for GDB to (1) connect and (2) send a "continue". Kind
of similar to how QEMU has -gdb/-s to enable the debug stub, and a
dedicated switch, -S, to suspend execution at startup until the debugger
says to resume?
Don't know how that would translate in terms of API (adding an argument to
rtems_debugger_start, if breaking the API is allowed; adding a function to
request the wait after rtems_debugger_start has been called; …); should I
open a separate feature request for this?
--
Ticket URL: <http://devel.rtems.org/ticket/4739#comment:4>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list