[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