shared library support

shared library support

[Stephen & Linda Smith]

I am slowly getting around to adding support for shared libraries to the 
newest GDB code base for a remote target.  The target I am currently 
interested in is target=powerpc-motorola-elf.  When I try and use the 
shared library functions that I used in the past I get a message that 
this "OS/ABI does not support shared libraries.

I checked in gdb/config/ and see files for ppc-eabi but not any for 
ppc-elf.  Is this the problem?

Stephen

Re: shared library support

[Kevin Buettner]

On Tue, 18 May 2004 06:37:28 -0700
Stephen & Linda Smith <ischis2@cox.net> wrote:

> I am slowly getting around to adding support for shared libraries to the 
> newest GDB code base for a remote target.  The target I am currently 
> interested in is target=powerpc-motorola-elf.  When I try and use the 
> shared library functions that I used in the past I get a message that 
> this "OS/ABI does not support shared libraries.
> 
> I checked in gdb/config/ and see files for ppc-eabi but not any for 
> ppc-elf.  Is this the problem?

I don't think so.

Where, precisely, is that message coming from?

Kevin

Re: shared library support

[Kevin Buettner]

On Tue, 18 May 2004 10:08:56 -0700
"Stephen P. Smith" <ischis2@cox.net> wrote:

> Kevin Buettner wrote:
> 
> >Where, precisely, is that message coming from?
> 
> I don't know where it is coming from.  I am using the insight tree, but 
> I have verified that the GDB code has been mucked with.  The source was 
> fetched on the 14th from CVS. 

Would you mind searching for the error message in your source tree?  I
looked for the message you quoted earlier today in a set of up-to-date
gdb sources, but came up empty.

You might also try placing a breakpoint on error() or warning() to
find out where this message is being generated.

Kevin

Re: shared library support

[Stephen P. Smith]

./gdb/solib-svr4.c
      warning ("no shared library support for this OS / ABI");

Sorry about misleading you.

sps

Kevin Buettner wrote:

>On Tue, 18 May 2004 10:08:56 -0700
>"Stephen P. Smith" <ischis2@cox.net> wrote:
>
>  
>
>>Kevin Buettner wrote:
>>
>>    
>>
>>>Where, precisely, is that message coming from?
>>>      
>>>
>>I don't know where it is coming from.  I am using the insight tree, but 
>>I have verified that the GDB code has been mucked with.  The source was 
>>fetched on the 14th from CVS. 
>>    
>>
>
>Would you mind searching for the error message in your source tree?  I
>looked for the message you quoted earlier today in a set of up-to-date
>gdb sources, but came up empty.
>
>You might also try placing a breakpoint on error() or warning() to
>find out where this message is being generated.
>
>Kevin
>
>
>  
>

Re: shared library support

[Kevin Buettner]

On Thu, 20 May 2004 11:04:45 -0700
"Stephen P. Smith" <ischis2@cox.net> wrote:

> ./gdb/solib-svr4.c
>       warning ("no shared library support for this OS / ABI");

Thanks for tracking this down.

If you truly want SVR4 shared library support for your target, you'll
need to supply some link map offsets for it to work.  See, e.g.,
ppc_linux_svr4_fetch_link_map_offsets() in ppc-linux-tdep.c.

Since you've implemented your own shared library support for your
target, my guess is that you don't want SVR4 shared library support
at all.  Exactly where we go next depends on how you've implemented
your shared library support.  Ideally, you would have written it
as a solib.c backend.  If you had, we could add some machinery for
enabling your backend in favor of the svr4 backend.  (Actually, the
machinery for switching amongst the various backends is long overdue,
so I'm kind of hoping this is what's needed.)

My recollection of the matter is that you didn't do it this way.  Did
you at least define SOLIB_ADD for your shared library support?  If so,
and if defined at the proper point, this definition will override the
solib.c infrastructure.  This is the mechanism that native AIX uses to
enable AIX shared library support in favor of that in solib.c /
solib-svr4.c.

Assuming that I'm right about my guesses thus far, probably the
easiest course is for you to define your own target (mytarget-tm.h /
mytarget.mt) such that your homebrew shared library support is listed
on the TDEPFILES line in the .mt file and some sort of SOLIB_ADD
define (even a null one) is made before the include of whatever ppc
target you're basing your homebrew target on.  If you use a null (or
otherwise bogus) SOLIB_ADD define, you'll want to #undef it after the
#include of tm-rs6000.h or similar.

The easiest course and the preferred course are not the same though. 
The preferred course is to write your shared library support as a
solib.c backend, add some OSABI recognition code for your target along
with a suitable OSABI-specific tdep.c file for your target.  In this
(latter) file, you would call some as yet to be written machinery in
solib.c which'd enable your target's shared library support.  This is
just a thumbnail sketch; if you choose to go this route, I'm willing
to go into much more detail and even assist with writing the necessary
solib.c support.

Kevin

Re: shared library support

[Stephen P. Smith]

./gdb/solib-svr4.c

     warning ("no shared library support for this OS / ABI");

Sorry about misleading you.

sps

Kevin Buettner wrote:

>On Tue, 18 May 2004 10:08:56 -0700
>"Stephen P. Smith" <ischis2@cox.net> wrote:
>
>  
>
>>Kevin Buettner wrote:
>>
>>    
>>
>>>Where, precisely, is that message coming from?
>>>      
>>>
>>I don't know where it is coming from.  I am using the insight tree, but 
>>I have verified that the GDB code has been mucked with.  The source was 
>>fetched on the 14th from CVS. 
>>    
>>
>
>Would you mind searching for the error message in your source tree?  I
>looked for the message you quoted earlier today in a set of up-to-date
>gdb sources, but came up empty.
>
>You might also try placing a breakpoint on error() or warning() to
>find out where this message is being generated.
>
>Kevin
>
>
>  
>

Re: shared library support

[Stephen P. Smith]

First I need to say that I didn't recieve the reply email from the 
redhat server but found the reply in the archives.
Therefore if this post looks like it follows up to the wrong message you 
know why.

KB> My recollection of the matter is that you didn't do it this way....The easiest course 
KB> and the preferred course are not the same though. The preferred course is to 
KB> write your shared library support as a solib.c backend, add some OSABI recognition 
KB> code for your target along with a suitable OSABI-specific tdep.c file for your target.  
KB> In this (latter) file, you would call some as yet to be written machinery in solib.c 
KB> which'd enable your target's shared library support.  This is just a thumbnail 
KB> sketch; if you choose to go this route, I'm willing to go into much more detail 
KB> and even assist with writing the necessary solib.c support.

In this case, and since some things have changed, I prefer to do it the correct way.  I may 
need quite abit of direction since I this will be my first major effort as long as you don't 
mind.  Kevin, would you please go into more detail about the solib.c support that you think 
is needed.

One of the things, besides what you have talked about already that may need done is what do 
about communicating with the remote target on this issue.  As far as I can tell, there 
isn't anything in the remote protocal for the target to let the host know (or for the host 
to ask) about shared libraries.  But that is for a future disussion.

Also would you want me to submit these changes as a series of small patches, or big ones. 

sps

Re: shared library support

[Kevin Buettner]

Stephen,

Sorry it took me so long to get back to you on this...

On Fri, 21 May 2004 13:42:19 -0700
"Stephen P. Smith" <ischis2@cox.net> wrote:

> In this case, and since some things have changed, I prefer to do it
> the correct way.  I may need quite abit of direction since I this
> will be my first major effort as long as you don't mind.  Kevin,
> would you please go into more detail about the solib.c support that
> you think is needed.

In many of the solib-*.c files, you'll see the following:

  /* FIXME: Don't do this here.  *_gdbarch_init() should set so_ops. */
  current_target_so_ops = &svr4_so_ops;

As indicated by the FIXME, we need some other mechanism for setting
the so_ops vector.  I think we'll want to do away with the global
``current_target_so_ops'' and create something equivalent using the
gdbarch_data machinery.  The per-architecture _gdbarch_init() function
will initialize the so_ops vector based on the OS/ABI.

This machinery is not dissimilar to the way that the link-map-offset
fetchers get set up for the various OS/ABIs that use solib-svr4.c
as its backend.  In a nutshell, we need to have something analogous
to set_solib_svr4_fetch_link_map_offsets() for setting the overall
solib backend.

---

As I've indicated in the past, you'll want to move your shared
library support into a solib-something.c file.  Look at (and mimic)
one or more of the following: solib-svr4.c, solib-irix.c, solib-aix5.c,
and solib-frv.c.  solib-aix5.c might be of particular interest.  Unlike
the the other solib backends listed above, this backend does NOT fetch
dynamic linker info from the target's memory.  It instead reads out of
some /proc files.  This means that solib-aix5.c will only work for native
targets.  This particular property is of zero interest to you, but the
fact that it uses a different (non-memory-based) mechanism for accessing
the dynamic linker data may be.

When I write a new solib backend -- I did one recently for FR-V/uClinux --
I make a copy one of the above mentioned files, say solib-svr4.c, rip
the guts out of each of the functions that implement the so_ops vector
and then delete any remaining unreferenced functions or data structures.
I then choose a representation for ``struct lm_info''.  (It's worth
comparing how this struct differs between each of the files I mention
above.)  Finally, I reimplement the various function comprising the
so_ops vector and add whatever supporting functions and data structures
that I find necessary.

> One of the things, besides what you have talked about already that
> may need done is what do about communicating with the remote target
> on this issue.  As far as I can tell, there isn't anything in the
> remote protocal for the target to let the host know (or for the host
> to ask) about shared libraries.  But that is for a future disussion.

Most of the current shared library backends read the dynamic linker
data out of memory.  I happen to like this approach because it means
that the shared library implementation stays the same for native and
remote targets.

That said, there are definitely some operating environments which
don't fit this mold and it'd be really nice to have a remote protocol
extension for handling it.  Please post your protocol related
proposals to gdb@sources.redhat.com.

> Also would you want me to submit these changes as a series of small
> patches, or big ones. 

We generally like looking at small patches better than large ones. 
That said, there are instances when large patches are acceptable.

One such case is when you want to show the overall direction that
you're taking.  In such a case, you can post a large patch, but
clearly indicate that you intend to break it up into smaller pieces
for actual review.

Also, new files are usually submitted all at once.  So, for example, 
if you had a new shared library backend called solib-foo.c, you'd
submit this file as part of a single patch.

Kevin