Re: shared library support

[Kevin Buettner <kevinb at redhat dot com>]

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