This is the mail archive of the gdb-prs@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]
Other format: [Raw text]

gdb/727: [RFC] Remote shared libraries


>Number:         727
>Category:       gdb
>Synopsis:       [RFC] Remote shared libraries
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 26 17:48:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     ac131313@redhat.com
>Release:        2001-07-30
>Organization:
>Environment:

>Description:
Stephen Smith <ischis2@home.com> wrote:

Andrew asked that the RFC for my remote shared library patch be
reposted  and updated in this forum.  The original posts to this
mailing list were in the 2/27/2001 to 3/21/2001 time frame and
finished with under the subject heading "GDB's remote protocol: My
proposed extention".  Since then I made some changes to get the shared
libraries working on the OS and that protocol is the subject of this
proposal.

Background

I am working with an embedded OS that has the ability to load and use
shared libraries which is capable of running programs compiled for
either the PE or ELF executable file formats.  The OS (and in this
case) the loader is part of software that must conform the the FAA
DO178-B regulations.  The part that interests me of this regulation
(for the discussion here) is that parts dealing with code coverage.
Because of the fact that the loader is part of the OS and because of
the regulations, any solutions that require adding code to the loader
to support the debugging of the libraries needed to be rejected.

When the OS loads the executable and the shared libraries, the various
segments (or is it sections) are not necessarily placed contiguously
in memory.  In fact, for this OS it would be amazing if it did.
Therefore part of the solution needed to be the ability to specify to
GDB where the various segment are in memory ( .text, .sdata, .sdata2,
etc. )

Another thing that needed considered was the amount of bandwidth that
would be used to support this optional protocol.  I kept in mind J.T.
Conklin's comment:


> > When would GDB issue this command?  Whenever the target stops?  We

don't want to add latency to the protocol.

The last thing that I considered of a general nature was how to load
the shared library symbol table.  The normal preferred method is to
have the remote stub or server call some function that GDB would
recognize and then have GDB load the symbol table.  One problem with
that in this case is that adding this code to the OS loader is not
allowed due to implications of the regulations cited above.  A larger
problem it turned out is that this OS splatters the segments
(sections?) all over a range of the virtual address space and doesn't
necessarily follow the normal rules for the PE/ELF formats.  In fact I
tried manually loading the symbol table giving the address of the
.text file and the data segment locations were totally incorrect.

Protocol

This protocol is encoded in the proposed
remote_get_list_of_shared_libraries() and a couple of supporting
functions.

First add two new queries qNewLibraries and qLibraries.  The reason
for two additions was to keep the communication bandwidth down and to
split the processing into increments.  The reason a shorted name
wasn't chosen was that the strings aren't very long and so that the
packets would be understandable.

If either of the two packets aren't implemented (they return an error)
or if the format of the returned string  is incorrect for the
qLibraries packet, the protocol is deemed to be unsupported and is
disabled.  This is to allow for backward compatibility and for systems
for which shared libraries don't exist (e.g. monolithic embedded
systems).

The qNewLibraries packet is used to find out if there are shared
libraries associated with the process and which have not been reported
to GDB.  If there are shared libraries and they haven't been reported,
a return of  '1' is expected, if no new shared libraries exist, a '0'
is returned.

An example might help:  an already running process which we are
suspending to debug that has shared libraries a.so and b.so.  Since
we are just starting, a '1' would be returned.  If later in the same
session a qNewLibraries packet is sent out and if no new libraries
have been loaded a '0' would be returned.

If a '1' has been returned, the a series of qLibraries packets would
be issued.  The return would be a string of the format "<filename>
<textaddress> [-mapped] [-readnow] [-s <secname> <addr>]*".  This
format was chosen because
     -  the code to support it was implemented elsewhere in GDB
     -  it supported giving addresses for an arbitrary number of
segments
     -  it allows for the use of symbol_file_add().
     -  it is file format independent.

When there aren't any more libraries to report a '\000' is returned.

In the above example there would be one packet for each of the a.so
and b.so libraries.  The reason that they weren't combined is because
the string length is unknown in the general case.  This isn't a
bandwidth hog because only one qLibraries packet is used for a shared
library per debugging session.

We have used this protocol over both a serial and a ethernet
connection and haven't noticed a speed differential between the two
links.  We haven't noticed a difference between a session that has
several shared libraries and one that doesn't have any.

Stephen Smith



>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


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