[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:
{{{
"cont"
}}}
Now a setting for a transports such as serial (which does not exist):
{{{
cont;serial=tty0:115000,8,1,e
}}}
and in time some adds support to load XML files so registers for a target
SoC can be seen by GDB:
{{{
"cont;serial=tty0:115000,8,1,e;xml=/xx/soc-abc.xml"
}}}
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