[sparc-solaris] unexpected warning when starting program

[sparc-solaris] unexpected warning when starting program

[Joel Brobecker]

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

Re: [sparc-solaris] unexpected warning when starting program

[Daniel Jacobowitz]

On Sun, Mar 11, 2007 at 10:16:46PM -0700, Joel Brobecker wrote:
> 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.

It's because you've forked, but the dynamic linker has not run yet.
This is code I added recently.  The first time, we get the name of the
dynamic linker from the contents of .interp.  Later, after it's run,
we get it from the inferior's link_map list.

Maybe a gdbarch hook to override the name of the default dynamic
linker?  That's really bizarre though.  Maybe the OpenSolaris sources
give some insight to how it came up with /lib/ld.so.1.


-- 
Daniel Jacobowitz
CodeSourcery

Re: [sparc-solaris] unexpected warning when starting program

[Joel Brobecker]

> Maybe a gdbarch hook to override the name of the default dynamic
> linker?  That's really bizarre though.

I agree it would be strange... Originally, I was thinking about
extending the target_so_ops, to provide a routine that would
tell us whether 2 SOs are identical or not. But I think this
belongs more in the gdbarch vector: This is a property of the target.
The way SOs work on solaris is not related to the fact that Solaris,
for a reason that we ignore, has two copies of the same dynamic loader.

It's really unfortunate to have to introduce an extra method just
to compensate for that, but how does everyone feel if I add this new
method which by default does what we do now (direct filename comparison),
but on Solaris would also treat ld.so as an exception?

-- 
Joel

Re: Re: [sparc-solaris] unexpected warning when starting program

[Denis PILAT]

Daniel Jacobowitz wrote:
> On Sun, Mar 11, 2007 at 10:16:46PM -0700, Joel Brobecker wrote:
>> 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.
>
> It's because you've forked, but the dynamic linker has not run yet.
> This is code I added recently. The first time, we get the name of the
> dynamic linker from the contents of .interp. Later, after it's run,
> we get it from the inferior's link_map list.
>
> Maybe a gdbarch hook to override the name of the default dynamic
> linker? That's really bizarre though. Maybe the OpenSolaris sources
> give some insight to how it came up with /lib/ld.so.1.
>
>
This "unexpected warning" is also the one that causes the TUI to crash 
under Solaris.
See the thread "TUI + gdbserver broken?" at url :
(http://sources.redhat.com/ml/gdb-patches/2007-03/msg00169.html)

Removing that warning (I've tried that as well) will remove that problem 
too, but it's only a side effect. I think we should fix both separately 
but when you'll have removed think warning, the TUI bug will become 
invisible.

-- 
Denis

Re: Re: [sparc-solaris] unexpected warning when starting program

[Daniel Jacobowitz]

On Tue, Mar 20, 2007 at 09:39:31AM +0100, Denis PILAT wrote:
> This "unexpected warning" is also the one that causes the TUI to crash under 
> Solaris.
> See the thread "TUI + gdbserver broken?" at url :
> (http://sources.redhat.com/ml/gdb-patches/2007-03/msg00169.html)
> 
> Removing that warning (I've tried that as well) will remove that problem too, 
> but it's only a side effect. I think we should fix both separately but when 
> you'll have removed think warning, the TUI bug will become invisible.

Hi Denis,

I seem to have lost my copy of that message so I can't reply to it,
but if you'll post it again with a ChangeLog, I'll approve it.  It
seems like a good place.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [sparc-solaris] unexpected warning when starting program

[Denis PILAT]

Daniel Jacobowitz wrote:
> On Tue, Mar 20, 2007 at 09:39:31AM +0100, Denis PILAT wrote:
>   
>> This "unexpected warning" is also the one that causes the TUI to crash under 
>> Solaris.
>> See the thread "TUI + gdbserver broken?" at url :
>> (http://sources.redhat.com/ml/gdb-patches/2007-03/msg00169.html)
>>
>> Removing that warning (I've tried that as well) will remove that problem too, 
>> but it's only a side effect. I think we should fix both separately but when 
>> you'll have removed think warning, the TUI bug will become invisible.
>>     
>
> Hi Denis,
>
> I seem to have lost my copy of that message so I can't reply to it,
> but if you'll post it again with a ChangeLog, I'll approve it.  It
> seems like a good place.
>
>   
Sorry for my late answer,
I'm about to do it on gdb-patches since gdbtui is still unusable under 
Solaris host

-- 
Denis

Re: [sparc-solaris] unexpected warning when starting program

[Eli Zaretskii]

> Date: Sun, 11 Mar 2007 22:16:46 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> 
> 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?

String comparisons is the wrong thing to do when the issue is file
equality.  This mostly works only by chance.  We should implement a
smarter FILENAME_CMP, IMHO.

Re: [sparc-solaris] unexpected warning when starting program

[Joel Brobecker]

> > 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?
> 
> String comparisons is the wrong thing to do when the issue is file
> equality.  This mostly works only by chance.  We should implement a
> smarter FILENAME_CMP, IMHO.

I completely agree, and I was planning on using FILENAME_CMP in any
solution we might come up with. But we also have to realize that
unless FILENAME_CMP also knows that on solaris /lib/ld.so is the
same as /usr/lib/ld.so (which is a possibility), then this isn't going
to make this particular warning go away...

-- 
Joel

Re: [sparc-solaris] unexpected warning when starting program

[Daniel Jacobowitz]

Looking at this again...

On Sun, Mar 11, 2007 at 10:16:46PM -0700, Joel Brobecker wrote:
> 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!!!

...

> 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?

xfullpath isn't really that expensive.  We could even do it only for
ld.so.1; I think that's not totally unreasonable.

Are you sure the files are distinct on your Solaris 2.8 / 2.9?  I have
a symlink /lib -> ./usr/lib on 2.8, and a symlink /usr/lib/ld.so.1 ->
../../lib/ld.so.1 on 2.10.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [sparc-solaris] unexpected warning when starting program

[Joel Brobecker]

> xfullpath isn't really that expensive.  We could even do it only for
> ld.so.1; I think that's not totally unreasonable.
> 
> Are you sure the files are distinct on your Solaris 2.8 / 2.9?  I have
> a symlink /lib -> ./usr/lib on 2.8, and a symlink /usr/lib/ld.so.1 ->
> ../../lib/ld.so.1 on 2.10.

Yes, on one of our Solaris 2.8 machines, they are distinct (although
identical):

bbk@nile ~>uname -a
SunOS nile 5.8 Generic_117350-24 sun4u sparc SUNW,Sun-Fire-V440 Solaris
bbk@nile ~>ls -l /lib/ld.so.1 /usr/lib/ld.so.1
-rwxr-xr-x    1 root     bin        267824 Feb 25  2005 /lib/ld.so.1*
-rwxr-xr-x    1 root     bin        267824 Feb 25  2005 /usr/lib/ld.so.1*
bbk@nile ~>md5sum /lib/ld.so.1 /usr/lib/ld.so.1
0e2c1ce2e68149904a5df691b32d5115  /lib/ld.so.1
0e2c1ce2e68149904a5df691b32d5115  /usr/lib/ld.so.1

I checked one of our Solaris 2.9 machines, and it's the same.

Thought it wouldn't help in these particular cases, it would
still help in the solaris 2.10 one...

-- 
Joel