[RTEMS Project] #4739: Fatal errors running GDB testcase against libdebugger

[RTEMS trac]

#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 Chris Johns):

 Replying to [comment:4 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?

 My pleasure and yes I agree it should be optional.

 > 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; …);

 I think breaking the API may be worth the short term pain. I tend to
 prefer a `const char* option` type argument that can be `NULL`. That
 argument can then be passed around and parsed by backends, transports etc
 and options can come and go without breaking the API.

 > should I open a separate feature request for this?

 Yes please and assign to me.

--
Ticket URL: <http://devel.rtems.org/ticket/4739#comment:5>
RTEMS Project <http://www.rtems.org/>
RTEMS Project