[RFA] Tru64 - wrong list of shared libraries

[RFA] Tru64 - wrong list of shared libraries

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

This happens on Tru64 with today's version of GDB, but compiled using
-DUSE_LDR_ROUTINES, which is not the default, but we noticed this
problem because ACT still uses the LDR routines.

Regression-tested on an alpha machine with Tru64 5.1A. The report shows
that it fixes 7 regressions. I also tested this change on Tru64 4.0f,
although I used a smaller set of tests because our Tru64 4.0f machine is
quite slow and heavily loaded.

Here is the ChangeLog entry:

2002-06-17  Joel Brobecker  <brobecker@gnat.com>

        * solib-osf.c (open_map): Compute the list of shread libraries
        loaded by the inferior, rather than the list of libraires loaded
        by GDB itself. Otherwise, GDB ends up reading the symbols from
        the wrong shared libraries...

And the regression tests summary on Tru64 5.1A:
       Number of tests 6919
       Summary 1       2
       FAIL    899     892
       PASS    6996    7003
       XFAIL   149     149
       XPASS   5       5
       Generating diff.html (Failure Table: Differences)
       Differences: 7

OK to commit?

Thanks,
-- 
Joel

[-- Attachment #2: solib-osf.c.diff --]
[-- Type: text/plain, Size: 735 bytes --]

Index: solib-osf.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-osf.c,v
retrieving revision 1.3
diff -c -3 -p -r1.3 solib-osf.c
*** solib-osf.c	1 Nov 2001 16:17:08 -0000	1.3
--- solib-osf.c	18 Jun 2002 05:44:18 -0000
*************** static int
*** 359,365 ****
  open_map (struct read_map_ctxt *ctxt)
  {
  #ifdef USE_LDR_ROUTINES
!   ctxt->proc = ldr_my_process ();
    if (ldr_xattach (ctxt->proc) != 0)
      return 0;
    ctxt->next = LDR_NULL_MODULE;
--- 359,365 ----
  open_map (struct read_map_ctxt *ctxt)
  {
  #ifdef USE_LDR_ROUTINES
!   ctxt->proc = ptid_get_pid (inferior_ptid);
    if (ldr_xattach (ctxt->proc) != 0)
      return 0;
    ctxt->next = LDR_NULL_MODULE;

Re: [RFA] Tru64 - wrong list of shared libraries

[Kevin Buettner]

On Jun 17, 10:47pm, Joel Brobecker wrote:

>         * solib-osf.c (open_map): Compute the list of shread libraries
>         loaded by the inferior, rather than the list of libraires loaded
>         by GDB itself. Otherwise, GDB ends up reading the symbols from
>         the wrong shared libraries...

I didn't understand your change at first, but that was due to the fact
that I didn't understand what ldr_my_process() does.  I've located some
documentation (via Google) and have remedied that situation.  As alluded
to in your ChangeLog entry, ldr_my_process() will retrieve the "unique
identifier" for the current process, i.e. gdb, which is clearly not
correct.

Presumably, the pid component of GDB's inferior_ptid is the same as
the "unique identifier" used by the ldr_ routines.  If it's not, then
we ought to be calling a function which does the translation.  I don't
know of any such function though, so I think your change is okay.  (For
the moment anyway.)

> OK to commit?

Yes, with the following changes...

First, fix the typos in your ChangeLog entry:

    s/shread/shared/
    s/libraires/libraries/
    s/itself. /itself.  /

Second, add a comment similar to the following just before the line
that you changed:

  /* Note: As originally written, ldr_my_process() was used to obtain
     the value for ctxt->proc.  This is incorrect, however, since
     ldr_my_process() retrieves the "unique identifier" associated
     with the current process (i.e. GDB) and not the one being
     debugged.  Presumably, the pid of the process being debugged is
     compatible with the "unique identifier" used by the ldr_
     routines, so we use that.  */

Thanks,

Kevin

Re: [RFA] Tru64 - wrong list of shared libraries

[Joel Brobecker]

> >         * solib-osf.c (open_map): Compute the list of shread libraries
> >         loaded by the inferior, rather than the list of libraires loaded
> >         by GDB itself. Otherwise, GDB ends up reading the symbols from
> >         the wrong shared libraries...
> >
> > OK to commit?
> 
> Yes, with the following changes...

Sorry for the long delay in answering. I made the adjustments you
requested, and committed the change. Thanks a lot for reviewing it.

-- 
Joel