[RTEMS Project] #4740: Teach libdebugger to wait for GDB to connect and ask to continue

RTEMS trac trac at rtems.org
Thu Oct 13 09:51:53 UTC 2022

#4740: Teach libdebugger to wait for GDB to connect and ask to continue
  Reporter:  Kévin Le Gouguec  |      Owner:  Chris Johns
      Type:  enhancement       |     Status:  assigned
  Priority:  normal            |  Milestone:
 Component:  lib/debugger      |    Version:
  Severity:  normal            |   Keywords:
Blocked By:                    |   Blocking:
 In #4739, Chris noted this snippet in the reproducer:

 /* Debugger lock, there is no way to ask the libdebugger to wait for a
  * connection, that would block the kernel.  Instead use the following
  * variable and 'set release_debugger = 1' in GDB when ready.  */
 volatile int release_debugger = 0;

 static void start_gdb_server(void)
   rtems_printer printer;
   int r;

   rtems_print_printer_fprintf(&printer, stdout);
   r = rtems_debugger_register_tcp_remote();
   if (r < 0) {
     perror("TCP remote register");

   r = rtems_debugger_start("tcp", "1122", 3, 1, &printer);
   if (r < 0) {
     perror("can't start debugger");

   /* Definitely not nice, but it doesn't seem like there is any other
    * for libdebugger based debugging.  GDB just has to setup and only then
    * set release_debugger variable.  */
   while (!release_debugger) {

 Chris suggests adding an option to make libdebugger halt execution until
 GDB connects and sends a "continue", which would make the debugging
 experience similar to targeting QEMU with the -S (uppercase S) switch:


 We would appreciate that option very much, as it would make our testsuite
 support code for RTEMS more akin to other platforms by getting rid of that
 release_debugger variable.

 The API has yet to be defined:

 > > 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.

 I know some programmers feel strongly against so-called "stringly-typed"
 APIs (e.g. they subvert type-checking; they require "𝖕𝖆𝖗𝖘𝖎𝖓𝖌"), but I've
 seen [https://flak.tedunangst.com/post/string-interfaces reasonable cases]
 for them; FWIW I do not have a clear preference for or against them in
 this context (C type-checking is a bit of a joke so not much is lost;
 parsing can be fraught but libdebugger probably does not belong in a
 critical stack anyway).

 So I'll trust your judgment on this!

 Again, thanks for suggesting this.

Ticket URL: <http://devel.rtems.org/ticket/4740>
RTEMS Project <http://www.rtems.org/>
RTEMS Project

More information about the bugs mailing list