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

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

[Mark Kettenis]

>  On Mon, Nov 10, 2008 at 8:19 PM, Daniel Jacobowitz <drow@false.org> wrote:
> > On Tue, Nov 11, 2008 at 06:10:46AM +0200, Eli Zaretskii wrote:
> >> I thought the original patch came with a suggestion to add an option,
> >> in case user wanted to see these messages.
> >
> > OK, I understand now.  I'd be fine with the shared library messages
> > disabled or made consistent under 'set verbose'.  I don't think adding
> > a new option would be great.
>
>  How about this?
>
>  I changed the calls to have_{partial,full}_symbols to two new
>  functions objfile_has_{partial,full}_symbols.  I think it's TRTTD
>  here.
>  This patch also adds a test for info_verbose so the messages are
>  printed for shared libs if verbosity turned on.

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. My perspective may be a bit different since I use an operating
system that ships all of its core libraries with full debug info. But we
really shouldn't consider proprietary operating systems as the norm here,
and we should encourage other Open Source systems to ship their libraries
with debug info.

>  2008-11-20  Doug Evans  <dje@google.com>
>
>          * objfiles.h (objfile_has_partial_symbols): Declare.
>          (objfile_has_full_symbols): Declare.
>          * objfiles.c (objfile_has_partial_symbols): New function.
>          (objfile_has_full_symbols): New function.
>          * symfile.c (symbol_file_add_with_addrs_or_offsets): Only print
>          "no debugging symbols found" for main program, unless the user
>          turns on verbosity.
>

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

[Eli Zaretskii]

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

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

[Doug Evans]

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.

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

[Eli Zaretskii]

> Date: Fri, 21 Nov 2008 09:06:18 -0800
> From: Doug Evans <dje@google.com>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, brobecker@adacore.com,
>         gdb-patches@sourceware.org
> 
> An alternative is to key the "no debugging symbols found" message off
> of "set print symbol-loading on" for shared libs.

That is fine with me, too, but perhaps people who say this verbosity
is annoying would want them off by default.

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

[Mark Kettenis]

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

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

[Doug Evans]

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]

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

[Eli Zaretskii]

> Date: Fri, 21 Nov 2008 14:53:39 -0800
> From: Doug Evans <dje@google.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, brobecker@adacore.com,
>         gdb-patches@sourceware.org
> 
> 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 agree that the current logic has its flaws, but I think I understand
the difficulty: the problem is with shared libraries that are part of
the program you are debugging vs system libraries, like libc.so.  We
probably do NOT want to hear about stripped system libraries by
default, but we do want those messages for libraries that are part of
the application, if the application isn't stripped.

Can we find a good way of supporting both these use cases?

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

[Paul Pluzhnikov]

On Sat, Nov 22, 2008 at 3:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Can we find a good way of supporting both these use cases?

Any library under /lib{,64}, /usr/lib{,64} and /usr/local/lib{,64}
is likely not an "application in development" library (although
there are obvious exceptions to this heuristic).

Another alternative: allow the user to "silence" specific
libraries via a glob pattern, e.g.

  set system-library "/lib*/libc.so.6 /lib*/libpthread.so.1"

The default could be "/lib* /usr/lib* /usr/local/lib*", which
would be equivalent to the heuristic above. A user who cares
about all libraries could reset this to "". A user who
doesn't care about any could set this to "*".

[Use ';' instead of space to separate patterns on *win* targets.]

Cheers,
-- 
Paul Pluzhnikov

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

[Eli Zaretskii]

> Date: Sat, 22 Nov 2008 11:07:48 -0800
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
> Cc: Doug Evans <dje@google.com>, mark.kettenis@xs4all.nl,         brobecker@adacore.com, gdb-patches@sourceware.org
> 
> On Sat, Nov 22, 2008 at 3:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Can we find a good way of supporting both these use cases?
> 
> Any library under /lib{,64}, /usr/lib{,64} and /usr/local/lib{,64}
> is likely not an "application in development" library (although
> there are obvious exceptions to this heuristic).
> 
> Another alternative: allow the user to "silence" specific
> libraries via a glob pattern, e.g.
> 
>   set system-library "/lib*/libc.so.6 /lib*/libpthread.so.1"
> 
> The default could be "/lib* /usr/lib* /usr/local/lib*", which
> would be equivalent to the heuristic above. A user who cares
> about all libraries could reset this to "". A user who
> doesn't care about any could set this to "*".

I'd prefer the latter method.

> [Use ';' instead of space to separate patterns on *win* targets.]

Yes, and Windows needs a different default for the system libraries.

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

[Doug Evans]

On Sun, Nov 23, 2008 at 8:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 22 Nov 2008 11:07:48 -0800
>> From: Paul Pluzhnikov <ppluzhnikov@google.com>
>> Cc: Doug Evans <dje@google.com>, mark.kettenis@xs4all.nl,         brobecker@adacore.com, gdb-patches@sourceware.org
>>
>> On Sat, Nov 22, 2008 at 3:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > Can we find a good way of supporting both these use cases?
>>
>> Any library under /lib{,64}, /usr/lib{,64} and /usr/local/lib{,64}
>> is likely not an "application in development" library (although
>> there are obvious exceptions to this heuristic).
>>
>> Another alternative: allow the user to "silence" specific
>> libraries via a glob pattern, e.g.
>>
>>   set system-library "/lib*/libc.so.6 /lib*/libpthread.so.1"
>>
>> The default could be "/lib* /usr/lib* /usr/local/lib*", which
>> would be equivalent to the heuristic above. A user who cares
>> about all libraries could reset this to "". A user who
>> doesn't care about any could set this to "*".
>
> I'd prefer the latter method.
>
>> [Use ';' instead of space to separate patterns on *win* targets.]
>
> Yes, and Windows needs a different default for the system libraries.

There's nothing in 'set system-library foo' that says it's for
suppressing "no debugging symbols found" messages.  I can imagine
someone down the road finding another use for wanting to know what the
system libraries are considered to be, but using "set system-library"
will mess with the "no debugging" suppression.  One could add an
additional option, set print system-library-symbol-loading on|off" (or
some such) akin to the current "set print symbol-loading on|off", or
change the latter to "set print symbol-loading off|normal|all" (or
some such, I didn't spend any time here thinking of good names :-)).
[The option was added after 6.8 so we should be able to change it
before the next release.]

Having to specify what the system library paths are is another
configuration parameter for ports, and if it's just used to suppress
"no debugging symbols found", I wonder if it's worth it though.

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

[Doug Evans]

[long message, short patch, but I wanted to give enough context. apologies]

Hi.  If I debug a stripped program gdb will print "no debugging symbols
found" for the main program and each shared library the program uses
(depending on certain conditions, see below).
It won't do this when the main program isn't stripped, even though some
shared libraries are, because the test for whether to do so or not
depends on whether at least one file isn't stripped.  If any file processed
thus far isn't stripped then no message is printed, and the main program is
(presumably) always at the head of the list.

src$ gcc -g hello.c -o hello.x
src$ gdb hello.x
GNU gdb (GDB) 6.8.50.20081003-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) r
Starting program: /home/dje/src/hello.x 
Hello.

Program exited normally.
(gdb) q
src$ strip hello.x
src$ gdb hello.x
GNU gdb (GDB) 6.8.50.20081003-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(no debugging symbols found)
(gdb) r
Starting program: /home/dje/src/hello.x 
(no debugging symbols found) <<< from /lib/ld-linux.so.2
(no debugging symbols found) <<< from system-supplied DSO at 0xffffe000
(no debugging symbols found) <<< from /lib/tls/i686/cmov/libc.so.6
Hello.

Program exited normally.
(gdb) 

This gets REALLY annoying if there are many shared libs.

It seems like we should print the message for the main binary,
regardless of whether the shared libs it uses are stripped or not.
This will happen today because it'll be the first one in the
objfile list and when it's loaded none of the shared libs have been
loaded yet so have_partial_symbols will always DTRT (so to speak).

Things get a bit twisted for shared libs because whether the message is
printed or not depends on the order the objfiles get processed in
(given the case where the main file doesn't have symbols).  Blech.
Once a shared lib with symbols is on the objfile chain, all the rest
will not have the message printed.  But if, say, there is only one shared
lib with symbols, and it is the last one loaded, all libraries (except
the last one of course) will trigger the message.

symfile.c:symbol_file_add_with_addrs_or_offsets:

  if (!have_partial_symbols () && !have_full_symbols ()
      && print_symbol_loading)
    {
      wrap_here ("");
      printf_unfiltered (_("(%s: no debugging symbols found)"),
			 objfile->name);
      ...
    }

have_partial_symbols and have_full_symbols will return 1 if any
objfile processed thus far has symbols, and each time we come through
here a new shared lib is added to the objfile list.

Given that there can be many shared libs, I'm not sure we should print
the message for each one of them.  Some users may find it useful,
and the message can be turned off completely by turning off printing
of symbol loading messages.   But given that this is only an issue when the
main program is stripped (at least in the current code), it seems like the
best solution is to only print the message for the main executable.
It doesn't seem worth it to get too fancy here, but I do want to
solve the problem of dozens if not hundreds of "no debugging symbols found"
being printed.

There is a second printing of this message in the code, when objfiles
are reread because they have changed.  I'm not sure that case should be
treated similarily - if a file goes from symbols to no symbols
I'd want to know.  So I'm leaving the second printing as is.
[grep for "no debugging symbols" in symfile.c, it occurs twice]

If you made it this far, thanks for reading, and here's my
suggested patch.  Fortunately there is a flag passed to
symbol_file_add_with_addrs_or_offsets that indicates whether
the file is the main program or not, so this is a trivial change.

An alternative patch would be to at least include the file name
in the message.  But if we do want to print this message for shared-libs
why should it be predicated on whether the main program is stripped or not?
We could of course add an option but it doesn't seem worth it.
Thus I'm leaning towards the patch below which just removes the message
for shared libs entirely.

2008-10-03  Doug Evans  <dje@google.com>

	* symfile.c (symbol_file_add_with_addrs_or_offsets): Only print
	"no debugging symbols found" for main program.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.218
diff -u -p -u -p -r1.218 symfile.c
--- symfile.c	3 Oct 2008 16:36:10 -0000	1.218
+++ symfile.c	3 Oct 2008 21:20:28 -0000
@@ -1048,7 +1048,13 @@ symbol_file_add_with_addrs_or_offsets (b
       xfree (debugfile);
     }
 
-  if (!have_partial_symbols () && !have_full_symbols ()
+  /* Only print "no debugging symbols found" for the main program,
+     there can be many shared libs and the message is more noise than
+     signal then.
+     Btw, if you think of printing this message for shared libs,
+     consider including the file name in the message.  */
+  if (mainline
+      && !have_partial_symbols () && !have_full_symbols ()
       && print_symbol_loading)
     {
       wrap_here ("");

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

[Joel Brobecker]

> An alternative patch would be to at least include the file name
> in the message.  But if we do want to print this message for shared-libs
> why should it be predicated on whether the main program is stripped or not?

I have to agree that the current situation is confusing. Before looking
at the patch itself, the first thing is to agree on what the debugger
should be doing at the user level. Perhaps there was a logic behind
the current implementation that we're not seeing yet.

IMO, a shared library without debugging symbol is a common and perfectly
normal occurrence, and thus does not deserve a warning - at least not
by default, particularly when the number of SOs becomes large. So I
would have to agree with the suggested patch.

What do others think?

-- 
Joel

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

[Doug Evans]

On Wed, Oct 29, 2008 at 8:04 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> An alternative patch would be to at least include the file name
>> in the message.  But if we do want to print this message for shared-libs
>> why should it be predicated on whether the main program is stripped or not?
>
> I have to agree that the current situation is confusing. Before looking
> at the patch itself, the first thing is to agree on what the debugger
> should be doing at the user level. Perhaps there was a logic behind
> the current implementation that we're not seeing yet.
>
> IMO, a shared library without debugging symbol is a common and perfectly
> normal occurrence, and thus does not deserve a warning - at least not
> by default, particularly when the number of SOs becomes large. So I
> would have to agree with the suggested patch.
>
> What do others think?

ping.

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

[Eli Zaretskii]

> Date: Fri, 7 Nov 2008 14:44:15 -0800
> From: Doug Evans <dje@google.com>
> 
> On Wed, Oct 29, 2008 at 8:04 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> >> An alternative patch would be to at least include the file name
> >> in the message.  But if we do want to print this message for shared-libs
> >> why should it be predicated on whether the main program is stripped or not?
> >
> > I have to agree that the current situation is confusing. Before looking
> > at the patch itself, the first thing is to agree on what the debugger
> > should be doing at the user level. Perhaps there was a logic behind
> > the current implementation that we're not seeing yet.
> >
> > IMO, a shared library without debugging symbol is a common and perfectly
> > normal occurrence, and thus does not deserve a warning - at least not
> > by default, particularly when the number of SOs becomes large. So I
> > would have to agree with the suggested patch.
> >
> > What do others think?
> 
> ping.

I think we should apply Doug's patch _and_ make the other change he
suggests as the "alternative" one, i.e. to print the file name as part
of the message for shared libraries.

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

[Daniel Jacobowitz]

On Sat, Nov 08, 2008 at 11:14:32AM +0200, Eli Zaretskii wrote:
> I think we should apply Doug's patch _and_ make the other change he
> suggests as the "alternative" one, i.e. to print the file name as part
> of the message for shared libraries.

Even a stripped shared library has more symbols than a stripped
executable, because more of the library will be in externally visible
entry points.  I agree with Joel - having a message print out for each
shared library is annoying when you have dozens of shared libraries
(common especially on Windows).  So how about we print out "(no
debugging symbols for my/binary.exe)" and not print out anything for
shared libraries?

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> Even a stripped shared library has more symbols than a stripped
> executable, because more of the library will be in externally visible
> entry points.  I agree with Joel - having a message print out for each
> shared library is annoying when you have dozens of shared libraries
> (common especially on Windows).  So how about we print out "(no
> debugging symbols for my/binary.exe)" and not print out anything for
> shared libraries?

Works for me!

-- 
Joel

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

[Eli Zaretskii]

> Date: Mon, 10 Nov 2008 09:45:28 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Doug Evans <dje@google.com>, brobecker@adacore.com,
> 	gdb-patches@sourceware.org
> 
> On Sat, Nov 08, 2008 at 11:14:32AM +0200, Eli Zaretskii wrote:
> > I think we should apply Doug's patch _and_ make the other change he
> > suggests as the "alternative" one, i.e. to print the file name as part
> > of the message for shared libraries.
> 
> Even a stripped shared library has more symbols than a stripped
> executable, because more of the library will be in externally visible
> entry points.  I agree with Joel - having a message print out for each
> shared library is annoying when you have dozens of shared libraries
> (common especially on Windows).  So how about we print out "(no
> debugging symbols for my/binary.exe)" and not print out anything for
> shared libraries?

It's been a long day, and I'm no longer sure I understand whether what
you are saying is something different from what I said.  Are you
saying that even if the user turns on the option to print this for
each shared library, we should not print that (or not have the
option)?  I'm okay with having such an option off by default, but I
was asking to display a file name if the option is ON.

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

[Daniel Jacobowitz]

On Mon, Nov 10, 2008 at 10:23:39PM +0200, Eli Zaretskii wrote:
> It's been a long day, and I'm no longer sure I understand whether what
> you are saying is something different from what I said.  Are you
> saying that even if the user turns on the option to print this for
> each shared library, we should not print that (or not have the
> option)?  I'm okay with having such an option off by default, but I
> was asking to display a file name if the option is ON.

I'm confused too - what option?

I think making the "no debugging symbols" message always include
filenames would be a useful improvement; no need of an option there.
I don't think that displaying the message for shared libraries is
particularly useful.  Maybe for "set verbose" though?

("help set verbose" is really uninformative.)

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Mon, 10 Nov 2008 15:44:31 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: dje@google.com, brobecker@adacore.com, gdb-patches@sourceware.org
> 
> On Mon, Nov 10, 2008 at 10:23:39PM +0200, Eli Zaretskii wrote:
> > It's been a long day, and I'm no longer sure I understand whether what
> > you are saying is something different from what I said.  Are you
> > saying that even if the user turns on the option to print this for
> > each shared library, we should not print that (or not have the
> > option)?  I'm okay with having such an option off by default, but I
> > was asking to display a file name if the option is ON.
> 
> I'm confused too - what option?

I thought the original patch came with a suggestion to add an option,
in case user wanted to see these messages.

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

[Daniel Jacobowitz]

On Tue, Nov 11, 2008 at 06:10:46AM +0200, Eli Zaretskii wrote:
> I thought the original patch came with a suggestion to add an option,
> in case user wanted to see these messages.

OK, I understand now.  I'd be fine with the shared library messages
disabled or made consistent under 'set verbose'.  I don't think adding
a new option would be great.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Doug Evans]

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

On Mon, Nov 10, 2008 at 8:19 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Nov 11, 2008 at 06:10:46AM +0200, Eli Zaretskii wrote:
>> I thought the original patch came with a suggestion to add an option,
>> in case user wanted to see these messages.
>
> OK, I understand now.  I'd be fine with the shared library messages
> disabled or made consistent under 'set verbose'.  I don't think adding
> a new option would be great.

How about this?

I changed the calls to have_{partial,full}_symbols to two new
functions objfile_has_{partial,full}_symbols.  I think it's TRTTD
here.
This patch also adds a test for info_verbose so the messages are
printed for shared libs if verbosity turned on.

2008-11-20  Doug Evans  <dje@google.com>

        * objfiles.h (objfile_has_partial_symbols): Declare.
        (objfile_has_full_symbols): Declare.
        * objfiles.c (objfile_has_partial_symbols): New function.
        (objfile_has_full_symbols): New function.
        * symfile.c (symbol_file_add_with_addrs_or_offsets): Only print
        "no debugging symbols found" for main program, unless the user
        turns on verbosity.

[-- Attachment #2: gdb-081120-symfile-3.patch.txt --]
[-- Type: text/plain, Size: 3464 bytes --]

2008-11-20  Doug Evans  <dje@google.com>

	* objfiles.h (objfile_has_partial_symbols): Declare.
	(objfile_has_full_symbols): Declare.
	* objfiles.c (objfile_has_partial_symbols): New function.
	(objfile_has_full_symbols): New function.
	* symfile.c (symbol_file_add_with_addrs_or_offsets): Only print
	"no debugging symbols found" for main program, unless the user
	turns on verbosity.

Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.79
diff -u -p -r1.79 objfiles.c
--- objfiles.c	5 Sep 2008 11:37:17 -0000	1.79
+++ objfiles.c	21 Nov 2008 01:18:12 -0000
@@ -675,6 +675,22 @@ objfile_relocate (struct objfile *objfil
   breakpoint_re_set ();
 }
 \f
+/* Return nonzero if OBJFILE has partial symbols.  */
+
+int
+objfile_has_partial_symbols (struct objfile *objfile)
+{
+  return objfile->psymtabs != NULL;
+}
+
+/* Return nonzero if OBJFILE has full symbols.  */
+
+int
+objfile_has_full_symbols (struct objfile *objfile)
+{
+  return objfile->symtabs != NULL;
+}
+
 /* Many places in gdb want to test just to see if we have any partial
    symbols available.  This function returns zero if none are currently
    available, nonzero otherwise. */
Index: objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.57
diff -u -p -r1.57 objfiles.h
--- objfiles.h	18 Nov 2008 21:31:26 -0000	1.57
+++ objfiles.h	21 Nov 2008 01:18:12 -0000
@@ -472,6 +472,10 @@ extern void free_all_objfiles (void);
 
 extern void objfile_relocate (struct objfile *, struct section_offsets *);
 
+extern int objfile_has_partial_symbols (struct objfile *);
+
+extern int objfile_has_full_symbols (struct objfile *);
+
 extern int have_partial_symbols (void);
 
 extern int have_full_symbols (void);
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.218
diff -u -p -r1.218 symfile.c
--- symfile.c	3 Oct 2008 16:36:10 -0000	1.218
+++ symfile.c	21 Nov 2008 01:18:12 -0000
@@ -1048,10 +1048,18 @@ symbol_file_add_with_addrs_or_offsets (b
       xfree (debugfile);
     }
 
-  if (!have_partial_symbols () && !have_full_symbols ()
+  /* Only print "no debugging symbols found" for the main program,
+     unless the user turns on verbosity.  There can be many shared libs
+     and the message is more noise than signal then.  */
+  if ((mainline || info_verbose)
+      && !objfile_has_partial_symbols (objfile)
+      && !objfile_has_full_symbols (objfile)
       && print_symbol_loading)
     {
       wrap_here ("");
+      /* No need to print the file name here for shared libs.
+	 We only get here for shared libs if info_verbose is set, and if
+	 info_verbose is set we've already printed the file name above.  */
       printf_unfiltered (_("(no debugging symbols found)"));
       if (from_tty || info_verbose)
         printf_unfiltered ("...");
@@ -2422,7 +2430,8 @@ reread_symbols (void)
 	         zero is OK since dbxread.c also does what it needs to do if
 	         objfile->global_psymbols.size is 0.  */
 	      (*objfile->sf->sym_read) (objfile, 0);
-	      if (!have_partial_symbols () && !have_full_symbols ())
+	      if (!objfile_has_partial_symbols (objfile)
+		  && !objfile_has_full_symbols (objfile))
 		{
 		  wrap_here ("");
 		  printf_unfiltered (_("(no debugging symbols found)\n"));

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

[Eli Zaretskii]

> Date: Thu, 20 Nov 2008 17:34:40 -0800
> From: Doug Evans <dje@google.com>
> 
> How about this?
> 
> I changed the calls to have_{partial,full}_symbols to two new
> functions objfile_has_{partial,full}_symbols.  I think it's TRTTD
> here.
> This patch also adds a test for info_verbose so the messages are
> printed for shared libs if verbosity turned on.

This is fine with me, thanks.  Please also see if the manual needs any
updates for this change.