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

[dje at google dot com (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 ("");