Re: GDB and shared libraries (was Re: Are you still with Suse)

Re: GDB and shared libraries (was Re: Are you still with Suse)

[Stephen Smith]

Kevin Buettner wrote:

> Last October, I made some changes to GDB's infrastructure to better
> support debugging of shared libraries in an embedded environment.
> But this infrastructure work will only really work for an SVR4-like
> shared library implementation (which, BTW, is what Linux uses).
>
> See http://sources.redhat.com/ml/gdb-patches/2000-10/msg00142.html

Ok,  when I run "$target-gcc -E -dM -x c /dev/null" I get

#define __PPC__ 1
#define _BIG_ENDIAN 1
#define PPC 1
#define __svr4__ 1
#define __GNUC_MINOR__ 95
#define __CHAR_UNSIGNED__ 1
#define _ARCH_PPC 1
#define __unix 1
#define __unix__ 1
#define __GNUC__ 2
#define _CALL_SYSV 1
#define __PPC 1
#define __BIG_ENDIAN__ 1
#define unix 1

so it appears that would be a canidate.

Which would you recommend:
    a) Patching my current code (the 5.0 release)
    b) Getting the latest snapshot

Re: GDB and shared libraries

[Kevin Buettner]

On Feb 26,  3:51pm, Stephen Smith wrote:

> > Last October, I made some changes to GDB's infrastructure to better
> > support debugging of shared libraries in an embedded environment.
> > But this infrastructure work will only really work for an SVR4-like
> > shared library implementation (which, BTW, is what Linux uses).
> >
> > See http://sources.redhat.com/ml/gdb-patches/2000-10/msg00142.html
> 
> Ok,  when I run "$target-gcc -E -dM -x c /dev/null" I get
> 
> #define __PPC__ 1
> #define _BIG_ENDIAN 1
> #define PPC 1
> #define __svr4__ 1
> #define __GNUC_MINOR__ 95
> #define __CHAR_UNSIGNED__ 1
> #define _ARCH_PPC 1
> #define __unix 1
> #define __unix__ 1
> #define __GNUC__ 2
> #define _CALL_SYSV 1
> #define __PPC 1
> #define __BIG_ENDIAN__ 1
> #define unix 1
> 
> so it appears that would be a canidate.

Maybe.  You'll need to dig deeper though to know if it'll really work. 
For starters, you'll need to determine if your dynamic loader calls
one of the magic symbols listed in solib_break_names[] in
solib-svr4.c.  Also, you'll need to verify that it exports the r_debug
struct via the mechanism used to find it by locate_base() in
solib-svr4.c.  In a nutshell, this means that the contents of the
.dynamic section as found on the target needs to have the value
corresponding to the DT_DEBUG tag be the address of the r_debug
struct.

> Which would you recommend:
>     a) Patching my current code (the 5.0 release)
>     b) Getting the latest snapshot

Get the latest snapshot.

However, you ought to first verify that your shared library
implementation is SVR4-like enough for it to help.  (See above.)

If it doesn't, you can take one of two approaches:

    1) Modify your shared library implementation so that solib-svr4.c
       (in the gdb sources) will work for you.  Recall that in private
       email I suggested defining SVR4_FETCH_LINK_MAP_OFFSETS for your
       target.  This is easy to do; just take a look at struct
       r_debug and struct link_map and figure out the offsets from
       the beginning of the struct to each member n the struct.
       Then construct a small function to fill in the fields of
       GDB's struct link_map_offsets.  You may even be able to
       use the example at

	   http://sources.redhat.com/ml/gdb-patches/2000-10/msg00147.html

       verbatim.

    2) Add a solib-yourtarget.c backend.  There are now two examples
       in the sources: solib-svr4.c and solib-aix5.c.  The eventual
       goal is to migrate the other shared library support to use this
       framework too.  (So don't look at the other shared library support
       that hasn't been migrated yet.  Or if you do, don't do it that
       way ;-)

Kevin

Re: GDB and shared libraries

[Stephen Smith]

>
> However, you ought to first verify that your shared library
> implementation is SVR4-like enough for it to help.  (See above.)
>
> If it doesn't, you can take one of two approaches:
>
>
>     2) Add a solib-yourtarget.c backend.  There are now two examples
>        in the sources: solib-svr4.c and solib-aix5.c.  The eventual
>        goal is to migrate the other shared library support to use this
>        framework too.  (So don't look at the other shared library support
>        that hasn't been migrated yet.  Or if you do, don't do it that
>        way ;-)
>
> Kevin

Since the other platform (that I have to get to work later) is x86 pe format I think I will go this route if necessary
(and then add the code back into the gdb baseline).

sps

Re: GDB and shared libraries

[Stephen Smith]

I take it you meant, Modify your shared library implementation of gdb...

Is that correct?

Kevin Buettner wrote:

>
>     1) Modify your shared library implementation so that solib-svr4.c
>        (in the gdb sources) will work for you.  Recall that in private
>        email I suggested defining SVR4_FETCH_LINK_MAP_OFFSETS for your
>        target.  This is easy to do; just take a look at struct
>        r_debug and struct link_map and figure out the offsets from
>        the beginning of the struct to each member n the struct.
>        Then construct a small function to fill in the fields of
>        GDB's struct link_map_offsets.  You may even be able to
>        use the example at
>
>            http://sources.redhat.com/ml/gdb-patches/2000-10/msg00147.html
>
>        verbatim.

Re: GDB and shared libraries

[Kevin Buettner]

On Feb 26,  5:40pm, Stephen Smith wrote:

> Kevin Buettner wrote:
> 
> >
> >     1) Modify your shared library implementation so that solib-svr4.c
> >        (in the gdb sources) will work for you.  Recall that in private
> >        email I suggested defining SVR4_FETCH_LINK_MAP_OFFSETS for your
> >        target.  This is easy to do; just take a look at struct
> >        r_debug and struct link_map and figure out the offsets from
> >        the beginning of the struct to each member n the struct.
> >        Then construct a small function to fill in the fields of
> >        GDB's struct link_map_offsets.  You may even be able to
> >        use the example at
> >
> >            http://sources.redhat.com/ml/gdb-patches/2000-10/msg00147.html
> >
> >        verbatim.
>
> I take it you meant, Modify your shared library implementation of gdb...
> 
> Is that correct?

No.

From your other email (including some of the private ones) it sounded
to me like you had the source to the OS and you could modify the
dynamic loader.  So I meant for the above to be split up into two
parts:

    a) OS / Library side work in making the dynamic loader behave
       like other SVR4 shared library implementations.

    b) In GDB, define SVR4_FETCH_LINK_MAP_OFFSETS for your target.

If you can do (a), then doing (b) will be trivial.  If you look over
some of my past email, you'll see that I've sketched out what needs
to be done for (a).

If you end up going the other route of adding a new solib backend
for GDB, you may still end up doing some work in the dynamic loader
anyway.  Basically, your dynamic loader and GDB need to agree on
an interface for 1) notifying GDB of when a shared object has been
loaded/unloaded, and 2) obtaining the names of the currently loaded
shared objects and their load addresses.

Kevin

Re: GDB and shared libraries

[Stephen Smith]

Let's pretend that my system is not SVR4 in nature and that I have source so a very minimal gdb server for an embedded
system that currently communicates with gdb for debugging of normal gcc applications.

Let's not assume that there are any special hooks in gdb for debugging shared libraries.  What commands or data would
the gdb server have to send to gdb to enable the debugging of shared libraries.

Stephen

Re: GDB and shared libraries

[Stephen Smith]

Ah, now I know why we are not communicating.

I have an embedded system with a proprietary OS.  This system has a minimal gdb server running on it.  Let's call this
the target
system.

My host is a Windows NT/Cygwin or Linux Box running gdb which is talking to the gdb server on the target machine.
The problem is that I have a process running on the target (no video, X, etc.) and am debugging on the host.  My process
uses a shared library and I need to add the capability of tracing into it.

Ok,  what do I need to add (commands, data, etc.) to my gdb server to trace into these libraries?  Is the spec written
down?

Kevin Buettner wrote:

> On Feb 26,  6:17pm, Stephen Smith wrote:
>
> > I am told that the "minimal" (and I don't know how minimal)
> > gdbserver doesn't follow the SVR4 spec.  Well, I could have fun.
>
> Okay, you've lost me.  Where does gdbserver enter into the picture?
>
> Kevin

Re: GDB and shared libraries

[Kevin Buettner]

Stephen,

Without knowing more about the shared library mechanism of the
proprietary embeddded OS, it is difficult to say.  For an SVR4-like
shared library system, gdb does not need any help from the target's
gdb server beyond that which it already provides (reading memory,
writing memory, etc) for normal debugging.  The reason for this is
that GDB is able to obtain all the information it needs regarding
the dynamic linker's activities from the memory of the target
process.  It is certainly possible that the OS you are dealing with
provides the information in a similar, albeit different way.

Or (more likely) it's possible that the OS provides some other
interface for getting at this information.  Again, the two things you
need are 1) some way to be notified that the dynamic linker has loaded
(or unloaded) one of the shared libraries and 2) some way to get the
names of the libraries, their load addresses, and perhaps other
assorted information.  You'll need to consult the docs for your
proprietary OS and figure out what these mechanisms are.  It's quite
possible that they've provided you with a debugging API for getting at
this information.

Anyway, once you've figured out these details, you'll still need to
put a shared library backend on your target.  Fortunately, if you make
the target stub (gdb server) do most of the work, it ought to be
pretty simple.  I think the generally accepted mechanism for gdb to
request this kind of target/stub-specific information is the "q"
packet.  GDB's remote protocol is documented at

    http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120

At this point, I'll let others jump in because my experience with the
remote protocol is actually rather limited...

Kevin

On Feb 26, 10:06pm, Stephen Smith wrote:
> Subject: Re: GDB and shared libraries
> Ah, now I know why we are not communicating.
> 
> I have an embedded system with a proprietary OS.  This system has a minimal gdb server running on it.  Let's call this
> the target
> system.
> 
> My host is a Windows NT/Cygwin or Linux Box running gdb which is talking to the gdb server on the target machine.
> The problem is that I have a process running on the target (no video, X, etc.) and am debugging on the host.  My process
> uses a shared library and I need to add the capability of tracing into it.
> 
> Ok,  what do I need to add (commands, data, etc.) to my gdb server to trace into these libraries?  Is the spec written
> down?
> 
> Kevin Buettner wrote:
> 
> > On Feb 26,  6:17pm, Stephen Smith wrote:
> >
> > > I am told that the "minimal" (and I don't know how minimal)
> > > gdbserver doesn't follow the SVR4 spec.  Well, I could have fun.
> >
> > Okay, you've lost me.  Where does gdbserver enter into the picture?
> >
> > Kevin
>-- End of excerpt from Stephen Smith

Re: GDB and shared libraries

[Stephen Smith]

>
> Or (more likely) it's possible that the OS provides some other
> interface for getting at this information.  Again, the two things you
> need are 1) some way to be notified that the dynamic linker has loaded
> (or unloaded) one of the shared libraries and 2) some way to get the
> names of the libraries, their load addresses, and perhaps other
> assorted information.  You'll need to consult the docs for your
> proprietary OS and figure out what these mechanisms are.  It's quite
> possible that they've provided you with a debugging API for getting at
> this information.
>

Well, since we wrote the OS and the gdbserver, I think that is doable.

>
> Anyway, once you've figured out these details, you'll still need to
> put a shared library backend on your target.  Fortunately, if you make
> the target stub (gdb server) do most of the work, it ought to be
> pretty simple.  I think the generally accepted mechanism for gdb to
> request this kind of target/stub-specific information is the "q"
> packet.  GDB's remote protocol is documented at
>
>     http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120
>
> At this point, I'll let others jump in because my experience with the
> remote protocol is actually rather limited...
>
> Kevin

Thanks for pointing me to the doc

Stephen

Re: GDB and shared libraries

[Andrew Cagney]

> Ok,  what do I need to add (commands, data, etc.) to my gdb server to trace into these libraries?  Is the spec written
> down?

Just FYI.

Most shared library implementations can, in theory, be debugged remotely
without any modifications to the GDB remote protocol.  This is because
the SHLIBs are handled using only memory read/writes and breakpoints.

The ``exercise left to the reader'' is getting what was native-only
SHLIB code re-written in a way that is host independant.

good luck,
	Andrew

Re: GDB and shared libraries

[Stephen Smith]

Andrew Cagney wrote:

> > Ok,  what do I need to add (commands, data, etc.) to my gdb server to trace into these libraries?  Is the spec written
> > down?
>
> Just FYI.
>
> Most shared library implementations can, in theory, be debugged remotely
> without any modifications to the GDB remote protocol.  This is because
> the SHLIBs are handled using only memory read/writes and breakpoints.
>
> The ``exercise left to the reader'' is getting what was native-only
> SHLIB code re-written in a way that is host independant.

From what I have been told and from looking at the spec it appears that I may have what I need already implemented as far as
the remote protocol is concerned (unless I missed something).  BTW, thanks kevin for your help.

Now here is an example that will go along with my question that hopefully will explain why I am so confused.  Remember I am
running
on target=powerpc-motorola-elf   and host = i686-cygwin-pe (this means that gdb is the insight version 5.0).

On the target I have the application testapp.exe and the library libtestlib.so.  When the OS loads testapp.exe and
libtestlib.so it does the fixups and (since we wrote the OS and the gdbserver) we can see the elf headers for both files.
We also currently can debug testapp.exe itself.

Now, the function main() has a call to lib1Func()  which is defined inside of libtestlib.so.  I would like to trace into
that function.

Questions:
     1)  In the protocol   http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120  I don't see a way to pass back the
fixup results that the loader performed.
          Don't I need to do that?

     2) When I step into the function, lib1Func(), how does the gdbserver tell gdb that it needs to load the symbol table
from the file libtestlib.so?

sps

Re: GDB and shared libraries

[Kevin Buettner]

On Feb 27,  2:15pm, Stephen Smith wrote:

> On the target I have the application testapp.exe and the library
> libtestlib.so.  When the OS loads testapp.exe and libtestlib.so it
> does the fixups and (since we wrote the OS and the gdbserver) we can
> see the elf headers for both files.  We also currently can debug
> testapp.exe itself.
> 
> Now, the function main() has a call to lib1Func() which is defined
> inside of libtestlib.so.  I would like to trace into that function.
> 
> Questions:
>      1)  In the protocol
>            http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120
>          I don't see a way to pass back the fixup results that the loader
>          performed.  Don't I need to do that?

Maybe, maybe not.  As Andrew indicated in his message, you might
be able to do it all by reading memory, writing memory, and setting
breakpoints.  In the event that you can't, I suggest using the "q"
packet so that GDB can fetch the shared library information from
gdbserver.  You'll need to modify gdb to generate (send) the "q"
packet at the appropriate point in the code (which will likely be in
your solib backend) and you'll need to modify gdbserver to recognize
your special "q" packet and return the shared library information in a
mutually agreed upon format.

>      2) When I step into the function, lib1Func(), how does the
>         gdbserver tell gdb that it needs to load the symbol table
>         from the file libtestlib.so?

The idea is for the symbol table to be loaded (by GDB) prior to ending
up in lib1Func().  For this to happen, GDB needs to be told when a
shared library has been loaded by the dynamic linker.  Again, one of
the ways this is commonly done is for gdb to set an internal
breakpoint in a special do-nothing function that the shared library
machinery agrees to call after it's loaded a shared library.  But it
could be done in other ways too.

Anyway, once GDB has been told that there are (potentially) new
libraries loaded, GDB then attempts to find the load information
that you refer to.  It then loads the symbol table and applies
the necessary relocations.

The point is that all of this occurs before you've ever hit lib1Func().

Kevin

Re: GDB and shared libraries

[Stephen Smith]

Now, I am getting somewhere!

Thanks.

Stephen

Re: GDB and shared libraries

[Stephen Smith]

Ok, my code shipment went out the other day, so I am back on this topic.  Since this is the first time I have ever
modified GNU code, you may have to bear with me.

For the record, I have read Section 13 of the gdb manual (especially the section on the q packet).  I also read my gdb
server
code, and kevin's solib-svr4.h and solib-svr4.c files. from the 20010306 snapshot.

First a couple of questions:
    1)  Andrew:  you state that "Most shared library implementations can, in theory, be debugged remotely
         without any modifications to the GDB remote protocol."  But, if kevin is correct, the q packet will have to
         have some additional features added.  Correct?
    2)  I am planning on adding a solib-remote-elf.h and solib-remote-elf.c files.
         where should I add the hooks in the rest of the files - I don't see where the svr4 stuff is hooked in and I haven't

         figured out where to hook into remote communications code for modifying the q packet (if I do have to modify the
protocol).

Thanks for helping the newbie.
sps

Below is the summary of the current discussion, just so we don't have to go over it.

>  Andrew Cagney
>  Just FYI.
>
>  Most shared library implementations can, in theory, be debugged remotely
>  without any modifications to the GDB remote protocol.  This is because
>  the SHLIBs are handled using only memory read/writes and breakpoints.
>
>  The ``exercise left to the reader'' is getting what was native-only
>  SHLIB code re-written in a way that is host independant.
>
>  good luck,
>          Andrew

>  Kevin Buettner wrote:
> > Stephen Smith wrote:
> > On the target I have the application testapp.exe and the library
> > libtestlib.so.  When the OS loads testapp.exe and libtestlib.so it
> > does the fixups and (since we wrote the OS and the gdbserver) we can
> > see the elf headers for both files.  We also currently can debug
> > testapp.exe itself.
> >
> > Now, the function main() has a call to lib1Func() which is defined
> > inside of libtestlib.so.  I would like to trace into that function.
> >
> > Questions:
> >      1)  In the protocol
> >            http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120
> >          I don't see a way to pass back the fixup results that the loader
> >          performed.  Don't I need to do that?
>
> Maybe, maybe not.  As Andrew indicated in his message, you might
> be able to do it all by reading memory, writing memory, and setting
> breakpoints.  In the event that you can't, I suggest using the "q"
> packet so that GDB can fetch the shared library information from
> gdbserver.  You'll need to modify gdb to generate (send) the "q"
> packet at the appropriate point in the code (which will likely be in
> your solib backend) and you'll need to modify gdbserver to recognize
> your special "q" packet and return the shared library information in a
> mutually agreed upon format.
>
> >      2) When I step into the function, lib1Func(), how does the
> >         gdbserver tell gdb that it needs to load the symbol table
> >         from the file libtestlib.so?
>
> The idea is for the symbol table to be loaded (by GDB) prior to ending
> up in lib1Func().  For this to happen, GDB needs to be told when a
> shared library has been loaded by the dynamic linker.  Again, one of
> the ways this is commonly done is for gdb to set an internal
> breakpoint in a special do-nothing function that the shared library
> machinery agrees to call after it's loaded a shared library.  But it
> could be done in other ways too.
>
> Anyway, once GDB has been told that there are (potentially) new
> libraries loaded, GDB then attempts to find the load information
> that you refer to.  It then loads the symbol table and applies
> the necessary relocations.
>
> The point is that all of this occurs before you've ever hit lib1Func().
>
> Kevin