This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libremote activation


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]