This is the mail archive of the gdb-patches@sourceware.org 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]

RFC: ppc-aix shared object support in GDB


Hello,

This is a question I am asking myself as part of my project of
cleaning up the ppc-aix solib & core file support in GDB.

I think that that ppc-aix model does not quite fit in GDB's
current solib model yet. Looking at struct so_list, it looks like
GDB assumes that, to each shared library dependency corresponds
a file (fields so_original_name and so_name). This makes sense
on a system like GNU/Linux, for instance, where a program depends
on .so files.

But on AIX, the problem is that the system "libraries" are in fact
archives containing shared objects, and that programs are linked
against those shared objects. For instance, here is what ldd shows
for a random program:

    /usr/local/bin/ls needs:
             /usr/lib/libc.a(shr.o)
             /usr/lib/libintl.a(libintl.so.1)

What ldd says is that ls depends on the shared object shr.o,
provided by the /usr/lib/libc.a archive.

In practice, what that means is that the so_name is no longer
sufficient, and a second piece of information would be needed
for two purposes:
  1. Being able to open the actual shared-object bfd instead
     of the archive's bfd;
  2. Have "info sharedlibrary" also display which shared object
     has been loaded instead of just the archive name.

(in terms of code, GDB would first create a bfd for /usr/lib/libc.a,
find that it is an archive, and then iterate over all its member
bfds until if finds one whose name is shr.o).

The most natural way to enhance the framework is to add a "member"
field. But then, we need to also upgrade the bfd_open target_so_ops
hook, as well as a number routines in solib.c which take a path to
identify a given shared dependency. For instance:

        bfd *solib_bfd_open (char *pathname)

At first glance, does it sound like a reasonable plan? I think
that definitely beats what's currently being done, which is
a certain amount of ad hoc code which takes care of opening
the bfds, creating the objfiles, doing the relocation, etc.
But perhaps there is something I haven't seen that we could use
already?

Thank you,
-- 
Joel


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