Re: too many "no debugging symbols found" messages from shared libs

[Doug Evans <dje at google dot com>]

On Fri, Nov 21, 2008 at 2:06 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>  On Fri, Nov 21, 2008 at 7:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Fri, 21 Nov 2008 13:57:24 +0100 (CET)
>> >> From: "Mark Kettenis" <mark.kettenis@xs4all.nl>
>> >> Cc: "Eli Zaretskii" <eliz@gnu.org>, brobecker@adacore.com,
>> >>         gdb-patches@sourceware.org
>> >>
>> >> Sorry I'm a bit late in this discussion, but I do really like the
>> >> messages
>> >> about missing symbol info for shared libraries.  To me they provide an
>> >> important hint that my debugging session is likely to run into problems
>> >> at
>> >> some point.
>> >
>> > You can still have that, just set the verbose option on.
>>
>>  An alternative is to key the "no debugging symbols found" message off
>>  of "set print symbol-loading on" for shared libs.  I kind of like this
>>  better.  It's on by default.  Folks with tons of shared libs probably
>>  want to turn symbol loading messages off anyway.
>
> I like that idea.

So did I until I ran the testsuite.  1/2 :-)

It turns out that this changes the behavior from what it is today.
Today, have_{partial,full}_symbols is used, and they return true if
_any_ file processed thus far has symbols.  So today if you're
debugging a program that has symbols you will never see the message
for shared libs.  It's only when debugging stripped programs that you
start seeing these messages for shared libs. [This behaviour is noted
in my original message, but I'd forgotten.]

I think the use of have_{partial,full}_symbols is wrong here - why
should libfoo.so having symbols affect whether we print the message
for libbar.so (if libbar is processed after libfoo)?  So part of what
I want to fix here is to test the file itself, not every file
processed thus far (hence the addition of
objfile_has_{partial,full}_symbols).  This is the easy part though.

The outstanding question is:  When debugging executables with symbols,
do we want to start printing "no debugging symbols found" messages for
every such shared library encountered as the default behavior?  If
yes, it can still be turned off with "set print symbol-loading off".
If no, then the user would have to turn on some other option in order
to see them ("set verbose on" is the current proposal).

Comments?

I don't have a preference, other than worries of complaints from users
when they start to see several new messages that they didn't use to
see before.

Today's behaviour:

gcc -g hello.c
gdb -ex 'run' -ex 'quit' a.out
[...]
Starting program: /tmp/a.out
Hello.

Program exited normally.

versus the following:

gcc -g hello.c
gdb -ex 'run' -ex 'quit' a.out
[...]
Starting program: /tmp/a.out
(no debugging symbols found in /lib/ld-linux.so.2)
(no debugging symbols found in system-supplied DSO at 0xffffe000)
(no debugging symbols found in /lib/tls/i686/cmov/libc.so.6)
Hello.

Program exited normally.

[or some such]