Re: [0/8] solib handler rework

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hello Joel,

> I tested on hppa-hpux (32-bit only, I don't have a 64-bit compiler),
> and on mips-irix. The good news is that testing on mips-irix showed
> no change. The other good news is that I saw no regression on hppa-hpux
> as well.

Thanks for testing!

> But there was a glitch: solib-pa64.c builds fine, but then
> I have unresolved symbol issues:
> 
> /usr/ccs/bin/ld: Unsatisfied symbols:
>    dlgetmodinfo (first referenced in libgdb.a(solib-pa64.o)) (code)
>    dlgetname (first referenced in libgdb.a(solib-pa64.o)) (code)

I was afraid something like that might be happening :-(

> This wasn't happening before simply because this entire file was
> ifdef'ed out when building 32-bit GDB. Why was it included in the first
> place if it was going to be ifdef'ed out?

This is all a bit unfortunate.  The problem is that hppa-hpux-tdep.c
contains references to both som_solib_select and pa64_solib_select,
so it needs to be linked against both solib-som.c and solib-pa64.c.

Now, solib-som.c appears to be platform-independent, and can be 
compiled everywhere, at least after the (unused) #include "som.h"
is removed.  However, solib-pa64.c depends crucially on header
files and library routines specific to 64-bit HP/UX, like
dlgetmodinfo.

The original code tried to resolve this in a somewhat weird manner:
both hpux and hpux64 targets would link against both solib-som.c
and solib-pa64.c, but the 32-bit target would define a special
PA_SOM_ONLY macro which prevents the bulk of solib-pa64.c from being
built, with the exception of a stub version of pa64_solib_select.

However, this would still break a multi-target build, and in fact
even any cross-build with hpux64 target, as it only selects the stub
version when building the 32-bit hpux targets.

Thus my patch tried to revert the logic: instead of having a conditional
when *not* to build the real solib-pa64.c, have a conditional that
selects when to *build* the real solib-pa64.c.  And in fact, that
conditional should be automatically computed by the configure process:
we want to build solib-pa64.c whenever its dependencies are present.

The way I attemted to implemented this is via a configure check for
the presence of the <elf_hp.h> header file, which I understand contains
the required structure definitions and prototypes needed by solib-pa64.c

This check did work as expected in my tests on non-HPUX systems,
and apparently it also works as expected in your 64-bit HPUX build.
However, it obviously isn't sufficient for a 32-bit HPUX build.

> Looking at the HP documentation, it looks like this symbol should be
> provided by -ldl (see http://docs.hp.com/en/B9106-90010/dlgetname.3C.html)
> but in fact, neither on HPUX 11.00 and 11.11 seems to provide libdl.
> On the other hand, I found these symbols inside libxpdl.sl. So it looks
> like we just need to add -lxpdl. I did this manually and that allowed
> me to complete the testing of your patch on hpux.

Hmmm, maybe that -lxpdl library is something new that was added to
allow 32-bit x 64-bit cross-debuggers to be implemented?  From the
comments in solib-pa64.c I got the impression that, at least originally,
accessing those routines on a 32-bit host was simply impossible ...

I guess there are two things to consider here:

- What additional test, besides the <elf_hp.h> header check, would
  allow us to distiguish between systems that provide the dlgetmodinfo
  etc routines and those that don't?

- If there is sometimes the need to add a special compatibility 
  library like -lxpdl, we need to add the appropriate configure
  magic to make that happen ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com