[sparc-solaris] unexpected warning when starting program

[Joel Brobecker <brobecker at adacore dot com>]

I have noticed the following new warning in GDB 6.6 when running
a program from GDB on sparc-solaris:

    (gdb) start
    Breakpoint 1 at 0x2d100: file a_test.adb, line 4.
    Starting program: /[...]/a_test 
    warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1"
    [New LWP 1]
    [New LWP 2]
    [New LWP 3]
    a_test () at a_test.adb:4
    4       procedure A_Test is

The warning is harmless, but a bit of an eyesore, and it also throws
off one of our testcases. I will see if I can enhance our testcase
to ignore that warning, but I thought I'd share what I have found.

Basically, the reason for the warning is that GDB thinks that the
inferior unloaded ld.so.1. The reason for that is that, during startup,
GDB does not immediately have access to base address of the dynamic
linker structs. I suspect that this is because our real inferior
hasn't been forked yet, or maybe is in the process of being forked.
I haven't had time to look further into this.

In this case, GDB falls back to a default method for computing
the list of SOs:

      debug_base = locate_base ();

      /* If we can't find the dynamic linker's base structure, this
         must not be a dynamically linked executable.  Hmm.  */
      if (! debug_base)
        return svr4_default_sos ();

This method returns one object, the dynamic linker, with the following
path: /usr/lib/ld.so.1.

Slightly later, GDB tries to update its list of shared libraries again,
and this time finds that base address. So it now scans a different
memory region for that list of shared libraries. And in addition to
that, there is the following code that was recently added:

      /* On Solaris, the dynamic linker is not in the normal list of
         shared objects, so make sure we pick it up too.  Having
         symbol information for the dynamic linker is quite crucial
         for skipping dynamic linker resolver code.  */
      if (lm == 0 && ldsomap == 0)
        lm = ldsomap = solib_svr4_r_ldsomap ();

The information extracted from this entry gives us the following path
to the loader: /lib/ld.so.1.  The paths are different!!!

As a result, when GDB updates its table of shared libraries, it thinks
these two entries are for different SOs, and thus unloads /usr/lib/ld.so.
The problem is that we already have an internal breakpoint in ld.so,
so GDB justifiably warns the user that one of the breakpoints inside
the given SO will have to be temporarily disabled.

I am a bit uncertain as to how to categorize this issue. Is this
something that we can avoid? Or should it be considered an OS issue?
I am not sure how to fix it either. On solaris 2.8 and 2.9, the two
files are identical but distinct - one is not a link to the other.
On solaris 2.10, however, one is a link of the other, so we could
presumably check the fullpath instead of doing a direct name comparison.
But that would be pretty expensive for just one type of host, no?

Any other idea?

-- 
Joel