Re: [PATCH RFA] solib.c reorg

[Kevin Buettner <kevinb at cygnus dot com>]

On Oct 23,  1:36pm, Peter.Schauer wrote:

> > I request approval for committing the patch below.
> 
> Thank you once again for another good GDB cleanup.
> 
> I would be volunteering to adapt osfsolib.c to your new scheme, if it gets
> accepted.

Cool.

> irix5-nat.c could get adapted as well, but I no longer have access to an
> IRIX machine.

Okay.  I think we still have some IRIX machines at Red Hat; I could
take a look at adapting it...

> Just a few observations:
> 
> - Why do you need solib-svr4.h, shouldn't the definitions be private
>   to solib-svr4.c ?

It is my intent to multiarch SVR4_FETCH_LINK_MAP_OFFSETS.  Then
an OS/ABI specific tdep.c file will be able to specify a function
which returns a struct link_map_offsets *.  But in order to do this,
I needed a mechanism to make struct link_map_offsets visible outside
of solib-svr4.c.

The reason, of course, for wanting to do this is so that it'll be
possible to build a cross debugger which can debug shared libraries
on the target.  (Even if the host has link.h, you can't count on
it being right for the target.)

Here's an example of how it might be done for a non-multiarched target
like Linux/x86.

In your tm.h file (assuming non-multiarched [1])...

struct link_map_offsets;
#define SVR4_FETCH_LINK_MAP_OFFSETS my_fetch_link_map_offsets
extern struct link_map_offsets *my_fetch_link_map_offsets (void);

In your OS/ABI specific tdep.c file (again assuming non-multiarched)...

#include "solib-svr4.h"
...

struct link_map_offsets *
my_fetch_link_map_offsets (void)
{
  static struct link_map_offsets lmo;
  static struct link_map_offsets *lmp = 0;

  if (lmp == 0)
    {
      lmp = &lmo;

      /* I think these are the correct offsets for Linux/x86...*/

      lmo.r_debug_size = 8;	/* Not actual size, but it gets us the
                                   fields that we need.  */

      lmo.r_map_offset = 4;
      lmo.r_map_size   = 4;

      lmo.link_map_size = 20;	/* Not actual size, but it gets us the
                                   fields that we need.  */

      lmo.l_addr_offset = 0;
      lmo.l_addr_size   = 4;

      lmo.l_name_offset = 4;
      lmo.l_name_size   = 4;

      lmo.l_next_offset = 12;
      lmo.l_next_size   = 4;

      lmo.l_prev_offset = 16;
      lmo.l_prev_size   = 4;
    }

    return lmp;
}

Once you have this in place (with the correct offsets and sizes for
your target), you should be able to debug host-cross-host programs
which use shared libraries.

> - The body of solib.c:_initialize_solib is conditionalized on HAVE_LINK_H.
>   This will not work for OSF or IRIX, if it is really needed, we will need
>   some other mechanism to exclude compilation of the body.

Good point.  There's no longer any reason for this ifdef.  I simply
missed it...

> - This code from solib.c:solib_map_sections
> 
>   for (p = so->sections; p < so->sections_end; p++)
>     {
>       /* Relocate the section binding addresses as recorded in the shared
>          object's file by the base address to which the object was actually
>          mapped. */
>       p->addr += TARGET_SO_LM_ADDR (so);
>       p->endaddr += TARGET_SO_LM_ADDR (so);
>       so->lmend = max (p->endaddr, so->lmend);
>       if (STREQ (p->the_bfd_section->name, ".text"))
>         {
>           so->textsection = p;
>         }
>     }
> 
>   might be to specialized for future targets, as it assumes that all sections
>   are loaded with the same offset (perhaps I will find some time someday
>   to convert the horrible AIX shlib code to your scheme, and then we will
>   definitely need it).

Yes, I know.

This is what I'll be working on next.  The real reason that I did this
reorg is because I'm working on AIX5/IA-64 for Monterey which will
require a somewhat different mechanism for handling shared libraries.
(It's similar to solib-svr4.c, but different enough to make most of
the code in that file unusable.)  So, I'll be writing a solib-aix5.c
file...

Anyway, sections are relocated by different amounts in AIX5 too, and
I plan to address the problem soon...

>   It might be better to perform the relocation via a target_so_ops entry.

Okay, thanks.  I hadn't thought that far ahead yet.

> - I am not sure if we shouldn't get rid of the TARGET_SO_LM_ADDR and
>   so->lmend crap altogether.
> 
>   solib_address could examine so->sections.
> 
>   info_sharedlibrary_command could put out the addresses of the textsection
>   (or of all sections, perhaps via a new `maint info sharedlibrary' command,
>   which I could have used quite often in the past).
> 
>   The lowest section handling in symbol_add_stub is questionable anyway
>   and needs some rethinking. I put in some debug output and ran the testsuite
>   on Solaris2 and Linux x86 targets, and it seems that all the business with
>   hacking sap->other[lowest_index].addr is not needed anyway, as
>   sap->other[lowest_index].addr == lowest_addr in all test cases.
>   I no longer have a SunOS4 platform handy, so perhaps it is needed there.

Thanks for the analysis.

>   But all that might be done in another round of changes as well.

Yeah, I think I'd prefer that.  This batch of changes is already
rather large and I think it'd be good to get it in before making
even more changes.

Kevin