Re: shared library support

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

shared library support hookin the remote.c

[Stephen & Linda Smith]

I have been trying to decide how to hook the solib support into the remote protocol and think that what is needed is a pointer to a function in remote.c.

Initially the pointer would be initailized to null (zero) and wouldn't be used unless the
solib supporting code initialized it to point to one of target specific functions.  The reason I came up with this idea is that the data that is needed by solib would in general not be the same between targets.  Also this would keep the code that is to handle this extension out of the remote.c file which is general in nature.  

With this resolved I think I can start coding (starting by adding this variable to the tree). It doesn't make much sense to write the solib support if I can't get the data out of the remote target.

What do you think

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Wed, 23 Jun 2004 18:55:40 -0700
Stephen & Linda Smith <ischis2@cox.net> wrote:

> I have been trying to decide how to hook the solib support into the
> remote protocol and think that what is needed is a pointer to a
> function in remote.c.
> 
> Initially the pointer would be initailized to null (zero) and
> wouldn't be used unless the solib supporting code initialized it to
> point to one of target specific functions.  The reason I came up
> with this idea is that the data that is needed by solib would in
> general not be the same between targets.  Also this would keep the
> code that is to handle this extension out of the remote.c file which
> is general in nature. 
> 
> With this resolved I think I can start coding (starting by adding
> this variable to the tree).  It doesn't make much sense to write the
> solib support if I can't get the data out of the remote target.
> 
> What do you think

I think we need more detail.  Which functions in remote.c would
be affected?   What would the interface look like and how would
it be used?

Also, please note that I am not the maintainer of remote.c...

Kevin

Re: shared library support hookin the remote.c

[Stephen P. Smith]

Kevin Buettner wrote:

>
>I think we need more detail.  Which functions in remote.c would
>be affected?   What would the interface look like and how would
>it be used?
>  
>
It would affetc remote_async_wait() and remote_wait().  From the last 
time, I know that we don't want to
add extraneous functionality to the remote protocol unless the target 
requires it.  This method would abstact
that out. 

What I haven't figured out is the preferred means of intializing such a 
variable across the two subsystems.

There would be a statement something like this:
   if ( remote_protocol_solib_hook_funcion )
       (*remote_protocol_solib_hook_funcion) ();

Does something like this seem reasonable?

>Also, please note that I am not the maintainer of remote.c...
>
>  
>
True  - but the use of this pointer would be in the solib area.  Since 
the target is always queried, this is the way the solib
subsystem would know when it is safe to ask about shared library values 
that it needs from a particular target.

sps

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Mon, 28 Jun 2004 14:41:24 -0700
"Stephen P. Smith" <ischis2@cox.net> wrote:

> Kevin Buettner wrote:
> 
> >I think we need more detail.  Which functions in remote.c would
> >be affected?   What would the interface look like and how would
> >it be used?
>
> It would affetc remote_async_wait() and remote_wait().  From the last 
> time, I know that we don't want to
> add extraneous functionality to the remote protocol unless the target 
> requires it.  This method would abstact
> that out. 

How does the remote target communicate the necessary details to GDB
then?

It sounds to me as though you want to add the hook so that you can add
a private protocol extension.

IMO, it's better to hash out the details of a public remote protocol
extension for shared library support.

> What I haven't figured out is the preferred means of intializing such a 
> variable across the two subsystems.
> 
> There would be a statement something like this:
>    if ( remote_protocol_solib_hook_funcion )
>        (*remote_protocol_solib_hook_funcion) ();
> 
> Does something like this seem reasonable?
> 
> >Also, please note that I am not the maintainer of remote.c...
>
> True  - but the use of this pointer would be in the solib area.  Since 
> the target is always queried, this is the way the solib
> subsystem would know when it is safe to ask about shared library values 
> that it needs from a particular target.

This may indeed be a reasonable way to approach things, but I'd like
to first understand how communication of shared library information
between GDB and the stub is accomplished and what the protocol looks
like.

Kevin

Re: shared library support hookin the remote.c

[Stephen & Linda Smith]

Kevin Buettner wrote:

> How does the remote target communicate the necessary details to GDB
>
>then?
>
>It sounds to me as though you want to add the hook so that you can add
>a private protocol extension.
>
>IMO, it's better to hash out the details of a public remote protocol
>extension for shared library support.
>
That would be my preference, but I haven't figured out a generic way.  
Here is the basic problem is that the
remote protocol has no notion of  shared libraries or of segments (TEXT, 
BSS, DATA, etc). Can someone
on this list think of a generic way of getting this data?

A second problem is that the number and names of the segments doesn't 
appear to be consistent.  It was for this
reason that I was thinking of making the protocol a target specific one 
that supports the solib interface. 

>... I'd like to first understand how communication of shared library information
>between GDB and the stub is accomplished and what the protocol looks
>like.
>

I assume you don't mean how the published protocol works.

What I didn't in the passed, was to use a q packet.  If I read the spec 
correctly was to use that packet type to find out if
there were any libraries and to find out the segment addersses.

I don't mind making it a public interface, but from the conversation 
three years ago, I got the idea that the maintainers
weren't especially keen on making it part of the general (i.e remote.c) 
code base.

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Mon, 28 Jun 2004 18:55:45 -0700
Stephen & Linda Smith <ischis2@cox.net> wrote:

> Kevin Buettner wrote:
> 
> > How does the remote target communicate the necessary details to GDB
> >
> >then?
> >
> >It sounds to me as though you want to add the hook so that you can add
> >a private protocol extension.
> >
> >IMO, it's better to hash out the details of a public remote protocol
> >extension for shared library support.
> >
> That would be my preference, but I haven't figured out a generic way.  
> Here is the basic problem is that the
> remote protocol has no notion of  shared libraries or of segments (TEXT, 
> BSS, DATA, etc). Can someone
> on this list think of a generic way of getting this data?

If you can have the stub report both the original and adjusted address
for the segments of a particular load object, GDB should be able to
determine which section(s) those segments belong to.  (Take a look at the
FR-V shared library support.)

> A second problem is that the number and names of the segments doesn't 
> appear to be consistent.  It was for this
> reason that I was thinking of making the protocol a target specific one 
> that supports the solib interface. 

I wouldn't worry about the names; I don't think there'll be any need to
communicate those.  As for the number of segments, the protocol should
be designed to handle an arbitrary number of segments.

> >... I'd like to first understand how communication of shared library information
> >between GDB and the stub is accomplished and what the protocol looks
> >like.
> >
> 
> I assume you don't mean how the published protocol works.
> 
> What I didn't in the passed, was to use a q packet.  If I read the spec 
> correctly was to use that packet type to find out if
> there were any libraries and to find out the segment addersses.
> 
> I don't mind making it a public interface, but from the conversation 
> three years ago, I got the idea that the maintainers
> weren't especially keen on making it part of the general (i.e remote.c) 
> code base.

I don't recall.  However, if the protocol is general enough to be usable
by a variety of targets, I see no reason for not including it in remote.c.
After all, qSymbol support is present in remote.c and that's only used for
some thread implementations.  It would be good to get buy-in from the
maintainer of remote.c before you start though.

Kevin

Re: shared library support hookin the remote.c

[Andrew Cagney]

Kevin, how does/should the existing remote GNU/Linux target work?
If we ignore the #ifdef SOLIB* code used during the initial attach, what 
components interact to maintain the shlibs?

Stephen, have you tried getting GDB to work native on your system?

There are several ways to dissect this so its important to identify all 
the components and their interactions.

Andrew

PS:
- I just deprecated all the existing ..._hook () calls :-)
- have a look at, and think about the File I/O packets, they effectively 
inject events into GDB.

> On Mon, 28 Jun 2004 18:55:45 -0700
> Stephen & Linda Smith <ischis2@cox.net> wrote:
> 
> 
>>> Kevin Buettner wrote:
>>> 
>>
>>>> > How does the remote target communicate the necessary details to GDB
>>>> >
>>>> >then?
>>>> >
>>>> >It sounds to me as though you want to add the hook so that you can add
>>>> >a private protocol extension.
>>>> >
>>>> >IMO, it's better to hash out the details of a public remote protocol
>>>> >extension for shared library support.
>>>> >
>>
>>> That would be my preference, but I haven't figured out a generic way.  
>>> Here is the basic problem is that the
>>> remote protocol has no notion of  shared libraries or of segments (TEXT, 
>>> BSS, DATA, etc). Can someone
>>> on this list think of a generic way of getting this data?
> 
> 
> If you can have the stub report both the original and adjusted address
> for the segments of a particular load object, GDB should be able to
> determine which section(s) those segments belong to.  (Take a look at the
> FR-V shared library support.)
> 
> 
>>> A second problem is that the number and names of the segments doesn't 
>>> appear to be consistent.  It was for this
>>> reason that I was thinking of making the protocol a target specific one 
>>> that supports the solib interface. 
> 
> 
> I wouldn't worry about the names; I don't think there'll be any need to
> communicate those.  As for the number of segments, the protocol should
> be designed to handle an arbitrary number of segments.
> 
> 
>>>> >... I'd like to first understand how communication of shared library information
>>>> >between GDB and the stub is accomplished and what the protocol looks
>>>> >like.
>>>> >
>>
>>> 
>>> I assume you don't mean how the published protocol works.
>>> 
>>> What I didn't in the passed, was to use a q packet.  If I read the spec 
>>> correctly was to use that packet type to find out if
>>> there were any libraries and to find out the segment addersses.
>>> 
>>> I don't mind making it a public interface, but from the conversation 
>>> three years ago, I got the idea that the maintainers
>>> weren't especially keen on making it part of the general (i.e remote.c) 
>>> code base.
> 
> 
> I don't recall.  However, if the protocol is general enough to be usable
> by a variety of targets, I see no reason for not including it in remote.c.
> After all, qSymbol support is present in remote.c and that's only used for
> some thread implementations.  It would be good to get buy-in from the
> maintainer of remote.c before you start though.
> 
> Kevin
> 

Re: shared library support hookin the remote.c

[Stephen P. Smith]

Andrew Cagney wrote:

> Stephen, have you tried getting GDB to work native on your system?
>
> There are several ways to dissect this so its important to identify 
> all the components and their interactions.

The system that I am working on has an OS that is used for embedded 
applications.  Therefore the only
way to debug is by a remote protocol or by emulator.  The host type is 
either i686-pc-elf or
powerpc-motorola-elf

As for native on my host - usually I am running on my cygwin box and 
things are working fine there.

Re: shared library support hookin the remote.c

[Andrew Cagney]

> 
> 
> Andrew Cagney wrote:
> 
>> Stephen, have you tried getting GDB to work native on your system?
>>
>> There are several ways to dissect this so its important to identify all the components and their interactions.
> 
> 
> The system that I am working on has an OS that is used for embedded applications.  Therefore the only
> way to debug is by a remote protocol or by emulator.  The host type is either i686-pc-elf or
> powerpc-motorola-elf
> 
> As for native on my host - usually I am running on my cygwin box and things are working fine there.

But assuming you could, what mechanisms would you use to implement it? :-)

Andrew

Re: shared library support hookin the remote.c

[Stephen P. Smith]

Andrew Cagney wrote:

>> The system that I am working on has an OS that is used for embedded 
>> applications.  Therefore the only
>> way to debug is by a remote protocol or by emulator.  The host type 
>> is either i686-pc-elf or
>> powerpc-motorola-elf
>>
>> As for native on my host - usually I am running on my cygwin box and 
>> things are working fine there.
>
>
> But assuming you could, what mechanisms would you use to implement it? 
> :-) 


Sorry, but I had to modify the old (non-gdb supported) implementation 
which had a side benifit of reminding me
what needed done.  Note that I am not saying that this has to be the 
protocol, just that I know it works with a minimal
amount of network bandwith.  Also note, that because of number 2 below, 
this support is backward compatible to older
stubs or to future stubs that don't care to support shared libraries.

1) Send a packet to the remote target asking if there are any shared 
libraries. 

2)  If the target sends back a '\0', then GDB knows that the target 
doesn't support this protocol and won't
and the rest of this protocol is unused for the remainder of the 
debugging session.  This keeps the traffic to a
minimum for stubs that don't support shared libraries (and we have a 
couple).

3) If the stub supports Step 1 it replies with a flag character.  We 
used '0' for none and '1' to not that there are some.

4)  If a '1' is returned in Step 3, then the following happens until 
there are no more libraries to  report.  The stub will only
     return the information for one shared library at a time so as not 
to over run a buffer in GDB.
 
      - a packet is sent asking for the shared library information.
       - The stub returns the library name and its location in memory 
which GDB uses to then load the symbol table correctly.

There are a couple of things that should be taken into acount for remote 
stubs.
1)  The remote OS may not provide a way for the stub to get an 
interrupt  or hook the library loading code but some may.  The
     OS I am involved with has that code in read-only memory.
2)  The OS may have already loaded the libraries by the time the stub 
gets control of the the process. 

It is for these two reasons that we don't use the breakpoint method that 
kevin is talking about.  I do like it for systems that can
support it - however.

sps

sps

Re: shared library support hookin the remote.c

[Andrew Cagney]

>> But assuming you could, what mechanisms would you use to implement it? :-) 
> 
> 
> 
> Sorry, but I had to modify the old (non-gdb supported) implementation which had a side benifit of reminding me
> what needed done.

Good :-)

> Note that I am not saying that this has to be the protocol, just that I know it works with a minimal
> amount of network bandwith.  Also note, that because of number 2 below, this support is backward compatible to older
> stubs or to future stubs that don't care to support shared libraries.
> 
> 1) Send a packet to the remote target asking if there are any shared libraries.
> 2)  If the target sends back a '\0', then GDB knows that the target doesn't support this protocol and won't
> and the rest of this protocol is unused for the remainder of the debugging session.  This keeps the traffic to a
> minimum for stubs that don't support shared libraries (and we have a couple).
> 
> 3) If the stub supports Step 1 it replies with a flag character.  We used '0' for none and '1' to not that there are some.
> 
> 4)  If a '1' is returned in Step 3, then the following happens until there are no more libraries to  report.  The stub will only
>     return the information for one shared library at a time so as not to over run a buffer in GDB.
> 
>      - a packet is sent asking for the shared library information.
>       - The stub returns the library name and its location in memory which GDB uses to then load the symbol table correctly.
> 
> There are a couple of things that should be taken into acount for remote stubs.
> 1)  The remote OS may not provide a way for the stub to get an interrupt  or hook the library loading code but some may.  The
>     OS I am involved with has that code in read-only memory.
> 2)  The OS may have already loaded the libraries by the time the stub gets control of the the process.
> It is for these two reasons that we don't use the breakpoint method that kevin is talking about.  I do like it for systems that can
> support it - however.

So each time the inferior stops, GDB will need to re-poll for shlib changes?

Can the stub instead generate a packet, very like the recently added F 
(File I/O) indicating that the link map changed (and what)?

I previously wrote:

> So its:
> 
> - an event indicating that the link map changed
> - in responce the solib code fetches the entire link map
> - the link map is merged against the current local cache
> - the objfile code is notified of any segment changes
> 
> It can be sliced 'n' diced at least two ways:
> 
> - at the objfile interface -> the protocol pushes changes to the link map
> 
> - a the solib interface -> the protocol pushes a ``something solib like happened'', and then the solib code pulls the link map.  If things are being done at this lower level, the protocol could even pass across the address/symbol at which the link map breakpoint should be inserted?
> 
> As for the information:
> 
>>>>> >     a) The unrelocated starting address of a segment.
> 
> Is this the offset in the object file.
> 
>>>>> >     b) The length of the segment
>>>>> >     c) The address (relocated) of the segment.
>>>>> >     d) The address space associated with the segment (think harvard
> 
> Rather than this is the protection mask needed (r,w,x?)
> 
>>>>> >        architecture here).
>>>>        f) object file path
> 
> How does this compare to what is found in /proc/*/*map*?

The other is to have a custom xxx-shlib hooked up to inferior stopped 
that queries for the stuff you describe.  It could probably be tunneled 
as a TARGET_OBJECT_KOD packet.

Andrew

Re: shared library support hookin the remote.c

[Stephen & Linda Smith]

Andrew Cagney wrote:

>
> So each time the inferior stops, GDB will need to re-poll for shlib 
> changes?

That is the way I currently have it set up.

There is one thing I don't understand about the F packet. How does the 
inferior know that it is OK to send the packet. From everything that I 
have read. Comunication is initiated by GDB and answered by the 
inferior. I didn't know that the stub could initiate a packet. If so, Do 
I just tack on the F packet information to the end of a currently 
generated packet?

This is the reason I was polling. Otherwise I prefer to not poll.

>
> Can the stub instead generate a packet, very like the recently added F 
> (File I/O) indicating that the link map changed (and what)?

I think I have answered this by answering the preceding question.

>
> The other is to have a custom xxx-shlib hooked up to inferior stopped 
> that queries for the stuff you describe. It could probably be tunneled 
> as a TARGET_OBJECT_KOD packet.
>
If I implement the F packet would that get rid if the need for a xxx-shlib?

RE: shared library support hookin the remote.c

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Stephen & Linda Smith
> Sent: 14 July 2004 19:30

> There is one thing I don't understand about the F packet. How 
> does the 
> inferior know that it is OK to send the packet. From 
> everything that I 
> have read. Comunication is initiated by GDB and answered by the 
> inferior. I didn't know that the stub could initiate a 
> packet. 


  I think that's exactly what happens when the inferior hits a breakpoint,
isn't it?  Gdb can't know that it's about to do that, so the stub is sending
a spontaneous (in the sense of not reqested by gdb) status or expedited
response packet.

  It occurs to me that "Send a gratuitious expedited response" might perhaps
the answer to that guy's question who wanted to invalidate gdb's cached
state.  Assuming he's only after invalidating the regcache, that is.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: shared library support hookin the remote.c

[Andrew Cagney]

> 
> Andrew Cagney wrote:
> 
>>
>> So each time the inferior stops, GDB will need to re-poll for shlib changes?
> 
> 
> That is the way I currently have it set up.
> 
> There is one thing I don't understand about the F packet. How does the inferior know that it is OK to send the packet. From everything that I have read. Comunication is initiated by GDB and answered by the inferior. I didn't know that the stub could initiate a packet. If so, Do I just tack on the F packet information to the end of a currently generated packet?

It's new code (added last year).  Instead of a normal stop, the inferior 
reports an F, once that is handled the inferior is resumed again. 
Corinna documented the interaction pretty well - see the relevant appendix.

> This is the reason I was polling. Otherwise I prefer to not poll.
> 
>>
>> Can the stub instead generate a packet, very like the recently added F (File I/O) indicating that the link map changed (and what)?
> 
> 
> I think I have answered this by answering the preceding question.
> 
>>
>> The other is to have a custom xxx-shlib hooked up to inferior stopped that queries for the stuff you describe. It could probably be tunneled as a TARGET_OBJECT_KOD packet.
>>
> If I implement the F packet would that get rid if the need for a xxx-shlib?

I think so.

Andrew

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Fri, 02 Jul 2004 16:20:19 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> Kevin, how does/should the existing remote GNU/Linux target work?
> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
> components interact to maintain the shlibs?

The existing GNU/Linux target knows just enough about the dynamic linker
(struct layout and symbol names) to be able to use memory reads to do the
entire thing.  I.e, all the information that GDB needs is either obtained
from the symbol table or from the address space of the target.

I am comfortable with this arrangement for GNU/Linux, but it isn't
adequate for all shared library scenarios.  E.g, I've worked on shared
library mechanisms in the past which used files from /proc to specify
the mappings.  It would be good if we could come up with a protocol
extension whereby the target supplies the information that GDB
needs.

I think we need the following:

1) A way to be notified when the shared library mappings have changed
2) A way to fetch the new mappings.  I think the following should
   be sufficient:
    a) The unrelocated starting address of a segment.
    b) The length of the segment
    c) The address (relocated) of the segment.
    d) The address space associated with the segment (think harvard
       architecture here).
    e) A way of iterating over the various segments.

solib-svr4.c does (1) by using breakpoints; i.e. a breakpoint is set
on a dynamic linker function which is always called when the mappings
change.  It does all of (2) by reading target memory.

Kevin

Re: shared library support hookin the remote.c

[Andrew Cagney]

> On Fri, 02 Jul 2004 16:20:19 -0400
> Andrew Cagney <cagney@gnu.org> wrote:
> 
> 
>>> Kevin, how does/should the existing remote GNU/Linux target work?
>>> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
>>> components interact to maintain the shlibs?
> 
> 
> The existing GNU/Linux target knows just enough about the dynamic linker
> (struct layout and symbol names) to be able to use memory reads to do the
> entire thing.  I.e, all the information that GDB needs is either obtained
> from the symbol table or from the address space of the target.

So, from the below, there's also an event bound to a breakpoint that 
triggers the entire thing?

> I am comfortable with this arrangement for GNU/Linux, but it isn't
> adequate for all shared library scenarios.  E.g, I've worked on shared
> library mechanisms in the past which used files from /proc to specify
> the mappings.  It would be good if we could come up with a protocol
> extension whereby the target supplies the information that GDB
> needs.

(See qPart)

>     a) The unrelocated starting address of a segment.
>     b) The length of the segment
>     c) The address (relocated) of the segment.
>     d) The address space associated with the segment (think harvard
>        architecture here).
>     e) A way of iterating over the various segments.
       f) object file path

For the /proc and SVR4 cases, did any of this information come from the 
object file?  Did you have a particular harvard architecture in mind?

I'm still not clear whats done with the information in this table once 
its created.

> solib-svr4.c does (1) by using breakpoints; i.e. a breakpoint is set
> on a dynamic linker function which is always called when the mappings
> change.  It does all of (2) by reading target memory.

Andrew

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Fri, 02 Jul 2004 18:25:22 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> > On Fri, 02 Jul 2004 16:20:19 -0400
> > Andrew Cagney <cagney@gnu.org> wrote:
> > 
> >>> Kevin, how does/should the existing remote GNU/Linux target work?
> >>> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
> >>> components interact to maintain the shlibs?
> > 
> > 
> > The existing GNU/Linux target knows just enough about the dynamic linker
> > (struct layout and symbol names) to be able to use memory reads to do the
> > entire thing.  I.e, all the information that GDB needs is either obtained
> > from the symbol table or from the address space of the target.
> 
> So, from the below, there's also an event bound to a breakpoint that 
> triggers the entire thing?

Yes.

> >     a) The unrelocated starting address of a segment.
> >     b) The length of the segment
> >     c) The address (relocated) of the segment.
> >     d) The address space associated with the segment (think harvard
> >        architecture here).
> >     e) A way of iterating over the various segments.
>        f) object file path

Yes (thanks), I forgot that one.

> For the /proc and SVR4 cases, did any of this information come from the 
> object file?

No.  The object file may appear to contain similar information (i.e. 
section addresses and lengths).  As noted below, the information
contained in (a)-(f) is used to generate relocation data for loading
an object file.

You will see solib-svr4.c consulting the object file.  It does this
to learn of certain addresses needed to location the above mentioned
information and for the address upon which to set a breakpoint.

> Did you have a particular harvard architecture in mind?

No.  We just need to provide for a way to distinguish between
potentially overlapping addresses.  If this is encoded in the address
in such a way that there can never be any ambiguity, then field (d) is
not needed.  I'm not convinced there's any way to guarantee this
though, which is why I suggested a separate field.

> I'm still not clear whats done with the information in this table once 
> its created.

It is used to generate relocation data for loading an object file's
symbols.  (See the call to symbol_file_add() in solib.c.)  Given a
segment obtained from (a)-(f), we need to find the corresponding
object file and sections.  We can then compute a relocation constant
by subtracting (a) from (c) to apply (add) to addresses associated
with each of the affected sections.

Kevin

Re: shared library support hookin the remote.c

[Andrew Cagney]

> On Fri, 02 Jul 2004 18:25:22 -0400
> Andrew Cagney <cagney@gnu.org> wrote:
> 
> 
>>>> > On Fri, 02 Jul 2004 16:20:19 -0400
>>>> > Andrew Cagney <cagney@gnu.org> wrote:
>>>> > 
>>>
>>>>>> >>> Kevin, how does/should the existing remote GNU/Linux target work?
>>>>>> >>> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
>>>>>> >>> components interact to maintain the shlibs?
>>>
>>>> > 
>>>> > 
>>>> > The existing GNU/Linux target knows just enough about the dynamic linker
>>>> > (struct layout and symbol names) to be able to use memory reads to do the
>>>> > entire thing.  I.e, all the information that GDB needs is either obtained
>>>> > from the symbol table or from the address space of the target.
>>
>>> 
>>> So, from the below, there's also an event bound to a breakpoint that 
>>> triggers the entire thing?
> 
> 
> Yes.
> 
> 
>>>> >     a) The unrelocated starting address of a segment.
>>>> >     b) The length of the segment
>>>> >     c) The address (relocated) of the segment.
>>>> >     d) The address space associated with the segment (think harvard
>>>> >        architecture here).
>>>> >     e) A way of iterating over the various segments.
>>
>>>        f) object file path
> 
> 
> Yes (thanks), I forgot that one.
> 
> 
>>> For the /proc and SVR4 cases, did any of this information come from the 
>>> object file?
> 
> 
> No.  The object file may appear to contain similar information (i.e. 
> section addresses and lengths).  As noted below, the information
> contained in (a)-(f) is used to generate relocation data for loading
> an object file.

An object file (at least elf) contains segment information.  I guess 
this is ignored?  (For those that are wondering, there's a subtle 
difference between segment and section :-).

> You will see solib-svr4.c consulting the object file.  It does this
> to learn of certain addresses needed to location the above mentioned
> information and for the address upon which to set a breakpoint.
> 
> 
>>> Did you have a particular harvard architecture in mind?
> 
> 
> No.  We just need to provide for a way to distinguish between
> potentially overlapping addresses.  If this is encoded in the address
> in such a way that there can never be any ambiguity, then field (d) is
> not needed.  I'm not convinced there's any way to guarantee this
> though, which is why I suggested a separate field.

Can we worry about this when it becomes a problem?

>>> I'm still not clear whats done with the information in this table once 
>>> its created.
> 
> 
> It is used to generate relocation data for loading an object file's
> symbols.  (See the call to symbol_file_add() in solib.c.)  Given a
> segment obtained from (a)-(f), we need to find the corresponding
> object file and sections.  We can then compute a relocation constant
> by subtracting (a) from (c) to apply (add) to addresses associated
> with each of the affected sections.

So its:

- an event indicating that the link map changed
- in responce the solib code fetches the entire link map
- the link map is merged against the current local cache
- the objfile code is notified of any segment changes

It can be sliced 'n' diced at least two ways:

- at the objfile interface -> the protocol pushes changes to the link map

- a the solib interface -> the protocol pushes a ``something solib like 
happened'', and then the solib code pulls the link map.  If things are 
being done at this lower level, the protocol could even pass across the 
address/symbol at which the link map breakpoint should be inserted?

As for the information:

 >>>> >     a) The unrelocated starting address of a segment.

Is this the offset in the object file.

 >>>> >     b) The length of the segment
 >>>> >     c) The address (relocated) of the segment.
 >>>> >     d) The address space associated with the segment (think harvard

Rather than this is the protection mask needed (r,w,x?)

 >>>> >        architecture here).
 >>>        f) object file path

How does this compare to what is found in /proc/*/*map*?

Andrew

Re: shared library support hookin the remote.c

[Kevin Buettner]

On Thu, 08 Jul 2004 11:03:54 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> > On Fri, 02 Jul 2004 18:25:22 -0400
> > Andrew Cagney <cagney@gnu.org> wrote:
> > 
> > 
> >>>> > On Fri, 02 Jul 2004 16:20:19 -0400
> >>>> > Andrew Cagney <cagney@gnu.org> wrote:
> >>>> > 
> >>>
> >>>>>> >>> Kevin, how does/should the existing remote GNU/Linux target work?
> >>>>>> >>> If we ignore the #ifdef SOLIB* code used during the initial attach, what 
> >>>>>> >>> components interact to maintain the shlibs?
> >>>
> >>>> > The existing GNU/Linux target knows just enough about the dynamic linker
> >>>> > (struct layout and symbol names) to be able to use memory reads to do the
> >>>> > entire thing.  I.e, all the information that GDB needs is either obtained
> >>>> > from the symbol table or from the address space of the target.
> >>
> >>> 
> >>> So, from the below, there's also an event bound to a breakpoint that 
> >>> triggers the entire thing?
> > 
> > 
> > Yes.
> > 
> > 
> >>>> >     a) The unrelocated starting address of a segment.
> >>>> >     b) The length of the segment
> >>>> >     c) The address (relocated) of the segment.
> >>>> >     d) The address space associated with the segment (think harvard
> >>>> >        architecture here).
> >>>> >     e) A way of iterating over the various segments.
> >>
> >>>        f) object file path
> > 
> > 
> > Yes (thanks), I forgot that one.
> > 
> >>> For the /proc and SVR4 cases, did any of this information come from the 
> >>> object file?
> > 
> > No.  The object file may appear to contain similar information (i.e. 
> > section addresses and lengths).  As noted below, the information
> > contained in (a)-(f) is used to generate relocation data for loading
> > an object file.
> 
> An object file (at least elf) contains segment information.  I guess 
> this is ignored?  (For those that are wondering, there's a subtle 
> difference between segment and section :-).

To the best of my knowledge, GDB doesn't currently use the segment
information contained in an executable.

> > You will see solib-svr4.c consulting the object file.  It does this
> > to learn of certain addresses needed to location the above mentioned
> > information and for the address upon which to set a breakpoint.
> > 
> > 
> >>> Did you have a particular harvard architecture in mind?
> > 
> > 
> > No.  We just need to provide for a way to distinguish between
> > potentially overlapping addresses.  If this is encoded in the address
> > in such a way that there can never be any ambiguity, then field (d) is
> > not needed.  I'm not convinced there's any way to guarantee this
> > though, which is why I suggested a separate field.
> 
> Can we worry about this when it becomes a problem?

Well, if we're trying to develop a protocol, we ought to at least make
it extensible so that it'll handle this case if/when it becomes a
problem.  Aside from this concern, I have no objection to leaving it
until later.

> >>> I'm still not clear whats done with the information in this table once 
> >>> its created.
> > 
> > 
> > It is used to generate relocation data for loading an object file's
> > symbols.  (See the call to symbol_file_add() in solib.c.)  Given a
> > segment obtained from (a)-(f), we need to find the corresponding
> > object file and sections.  We can then compute a relocation constant
> > by subtracting (a) from (c) to apply (add) to addresses associated
> > with each of the affected sections.
> 
> So its:
> 
> - an event indicating that the link map changed
> - in responce the solib code fetches the entire link map
> - the link map is merged against the current local cache
> - the objfile code is notified of any segment changes
> 
> It can be sliced 'n' diced at least two ways:
> 
> - at the objfile interface -> the protocol pushes changes to the link map
> 
> - a the solib interface -> the protocol pushes a ``something solib like 
> happened'', and then the solib code pulls the link map.  If things are 
> being done at this lower level, the protocol could even pass across the 
> address/symbol at which the link map breakpoint should be inserted?
> 
> As for the information:
> 
>  >>>> >     a) The unrelocated starting address of a segment.
> 
> Is this the offset in the object file.

Yeah, this should be the segment offset from the executable.

>  >>>> >     b) The length of the segment
>  >>>> >     c) The address (relocated) of the segment.
>  >>>> >     d) The address space associated with the segment (think harvard
> 
> Rather than this is the protection mask needed (r,w,x?)

I don't think this is really needed.  Though having it wouldn't hurt
if you want an additional check to make sure that you've found an
appropriate section.

>  >>>> >        architecture here).
>  >>>        f) object file path
> 
> How does this compare to what is found in /proc/*/*map*?

I'm not sure where you're going with this.

It's useful to have the original segment address and length in order
to find the corresponding sections.  If you don't have this
information, you have to try to determine it by playing games with
things like the protection mask or perhaps the order of the entries in
the map file.  I've done this before on AIX/IA64 and it was not fun.

It's not at all clear to me though what any of this has to do with
Stephen's orignal question.

Kevin

Re: shared library support hookin the remote.c

[Andrew Cagney]

>>> As for the information:
>>> 
>>>  >>>> >     a) The unrelocated starting address of a segment.
>>> 
>>> Is this the offset in the object file.
> 
> 
> Yeah, this should be the segment offset from the executable.
> 
> 
>>>  >>>> >     b) The length of the segment
>>>  >>>> >     c) The address (relocated) of the segment.
>>>  >>>> >     d) The address space associated with the segment (think harvard
>>> 
>>> Rather than this is the protection mask needed (r,w,x?)
> 
> 
> I don't think this is really needed.  Though having it wouldn't hurt
> if you want an additional check to make sure that you've found an
> appropriate section.

If GDB knows a segment is read-only, it also knows that it can cache it 
-> especially important for text sections.

>>>  >>>> >        architecture here).
>>>  >>>        f) object file path
>>> 
>>> How does this compare to what is found in /proc/*/*map*?
> 
> 
> I'm not sure where you're going with this.

If we had access to the remote's /proc/*/map* (or a faked up 
equivalent), could we obtain the necessary information?

> It's useful to have the original segment address and length in order
> to find the corresponding sections.  If you don't have this
> information, you have to try to determine it by playing games with
> things like the protection mask or perhaps the order of the entries in
> the map file.  I've done this before on AIX/IA64 and it was not fun.
> 
> It's not at all clear to me though what any of this has to do with
> Stephen's orignal question.

Andrew

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