From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20135 invoked by alias); 22 Oct 2007 13:42:35 -0000 Received: (qmail 20124 invoked by uid 22791); 22 Oct 2007 13:42:34 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 22 Oct 2007 13:42:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9MDgS4e173672 for ; Mon, 22 Oct 2007 13:42:28 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9MDgSgE1319042 for ; Mon, 22 Oct 2007 15:42:28 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l9MDgRPb009202 for ; Mon, 22 Oct 2007 15:42:28 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l9MDgRJO009199; Mon, 22 Oct 2007 15:42:27 +0200 Message-Id: <200710221342.l9MDgRJO009199@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 22 Oct 2007 15:42:27 +0200 Subject: Re: [0/8] solib handler rework To: brobecker@adacore.com (Joel Brobecker) Date: Mon, 22 Oct 2007 13:44:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20071022032134.GA764@adacore.com> from "Joel Brobecker" at Oct 21, 2007 08:21:34 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00502.txt.bz2 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 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 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