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

RTEMS trac trac at rtems.org
Fri Oct 14 02:12:44 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            |  Resolution:
 Keywords:                    |  Blocked By:
 Blocking:                    |

Comment (by Chris Johns):

 Replying to [comment:1 Kévin Le Gouguec]:
 > (Woops, looks like part of my OP got bitten off. Here it is, without the
 weird Unicode characters that presumably caused it to be truncated?)
 > I know some programmers feel strongly against so-called "stringly-typed"
 APIs (e.g. they subvert type-checking; they require "parsing"), 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).

 The statements are true and valid however given the context I see more
 value in a set of string options. The link you provide is great. I will
 add to the list of examples the NFS options to a kernel such as FreeBSD.

 Libdebugger will expand and grow in ways we might not appreciate today and
 I do not see value in maintaining C code to do this. The first example is
 `continue`. I would make waiting the default as GDB does when you connect
 to a running process. A continue option would be:
 Now a setting for a transports such as serial (which does not exist):
 and in time some adds support to load XML files so registers for a target
 SoC can be seen by GDB:
 The options can be easily and cheaply passed around and then used as
 needed by different subsystems in `libdebugger`.

 > So I'll trust your judgment on this!

 It is also the lazy alternative so maybe you should not ;)

 > Again, thanks for suggesting this.

 No problem.

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

More information about the bugs mailing list