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


First, apologies for not getting libremote sources out to the public
yet.  We fully plan to release all libremote sources to the public in
the near future.  The only reason we haven't to date is a lack of
available resources to do it properly.

Libremote is our effort to make a standard framework under a single set
of sources for handling GDB remote protocol on the target side.  We plan
on releasing the code under a BSD like license.  This will eliminate
worries of linking this code with third party proprietary libraries.


Eric Bachalo
Director of Engineering
Red Hat, Inc.




"J.T. Conklin" wrote:
> 
> >>>>> "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]