This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: libremote activation
- To: Rudy Folden <rfolden at redhat dot com>
- Subject: Re: libremote activation
- From: jtc at redback dot com (J.T. Conklin)
- Date: 09 Nov 2000 14:35:48 -0800
- Cc: gdb at sourceware dot cygnus dot com
- References: <3A0B0F63.254C569A@redhat.com>
- Reply-To: jtc at redback dot com
>>>>> "Rudy" == Rudy Folden <rfolden@redhat.com> writes:
Rudy> Michael Snyder and I are working on what we believe to be the
Rudy> first native version of libremote for an embedded Linux system.
Thanks for the explanation of what libremote is. Note that I make the
following suggestions knowing pretty much nothing about it.
* If GDB, or the remote protocol, needs to be changed in any way to
support automatic activation of libremote, there needs to be more
disclosure about what it is. Even if it's kept redhat proprietary,
we'll need a spec so we can properly interface with it.
* Your comments about starting libremote via an inetd like mechanism
vs. starting it at runtime seem somewhat contradictory. Yes, many
embedded systems have little memory, but the footprint of a debug
agent should be very small (10-20K). If you have room to run an
inetd like program, you should be able to run a debug agent as well.
Note, if inetd is spawning the program, it's going to take the same
amount of memory as if it was spawned at system startup.
* Your comments about libremote stopping after GDB exits and needing
an instance for each program under debug are manifestations of
design bugs in the remote protocol. A single debug agent should be
able to be started at system bringup; support debugging any number
of processes (and any number of threads); and should not exit when
GDB quits. In order for the debug agent not to have to manage
multiple communication channels, that might be handled by a host-
side proxy.
--jtc
--
J.T. Conklin
RedBack Networks