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

[RTEMS trac]

#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:

 {{{
 #!c
 /* Debugger lock, there is no way to ask the libdebugger to wait for a
  * connection, that would block the kernel.  Instead use the following
 global
  * 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");
     abort();
   }

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

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

 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:

 https://www.qemu.org/docs/master/system/gdb.html#gdb-usage

 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