[patch] suppress annoying warnings about cygwin1.dbg

[patch] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

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


If you use Insight with Cygwin, you are treated to two extremely
annoying pop-up warnings every time you debug any program:

section .text not found in /bin/cygwin1.dbg
no loadable sections found in added symbol-file /bin/cygwin1.dbg

This is because the debug symbols for the Cygwin DLL itself are handled
specially.  The DLL has only a .gnu_debuglink section which points to an
external file that holds the symbols, cygwin1.dbg.  This file contains
only debug sections, no code, and thus every time gdb reads it with bfd,
it issues these warnings in symfile.c:syms_from_objfile().

When using the plain gdb front-end, stdout and stderr have been
conveniently redirected to /dev/null by
win32-nat.c:safe_symbol_file_add().  However, since Insight hooks
warning() through gdbtk_warning(), it gets all messages and doesn't know
to ignore them.  This patch just adds a regexp in gdbtk_tcl_warning to
filter these messages.  I can think of cleaner solutions to doing this,
such as having gdbtk_warning() check stdout/stderr, but it looks like
this is the established way of doing things so here it is.

Brian

[-- Attachment #2: insight_cygwin_nags.patch --]
[-- Type: text/plain, Size: 965 bytes --]

2007-04-18  Brian Dessent  <brian@dessent.net>

	* library/interface.tcl (gdbtk_tcl_warning): Suppress useless warnings
	when loading symbols from cygwin1.dbg.

Index: library/interface.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
retrieving revision 1.57
diff -u -p -r1.57 interface.tcl
--- library/interface.tcl	23 Dec 2005 18:26:50 -0000	1.57
+++ library/interface.tcl	18 Apr 2007 14:24:16 -0000
@@ -365,6 +365,8 @@ proc gdbtk_tcl_warning {message} {
 
   switch -regexp $message {
         "Unable to find dynamic linker breakpoint function.*" {return}
+	"(no loadable sections|section .* not) found in .*cygwin.*\.dbg"
+	                                                      {return}
 	"Internal error.*" { gdbtk_tcl_fputs_error $message }
         "incomplete CFI.*" { gdbtk_tcl_fputs_error $message }
 	"RTTI symbol not found for class.*" { gdbtk_tcl_fputs_error $message }

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Christopher Faylor]

On Wed, Apr 18, 2007 at 07:37:46AM -0700, Brian Dessent wrote:
>
>If you use Insight with Cygwin, you are treated to two extremely
>annoying pop-up warnings every time you debug any program:
>
>section .text not found in /bin/cygwin1.dbg
>no loadable sections found in added symbol-file /bin/cygwin1.dbg
>
>This is because the debug symbols for the Cygwin DLL itself are handled
>specially.  The DLL has only a .gnu_debuglink section which points to an
>external file that holds the symbols, cygwin1.dbg.  This file contains
>only debug sections, no code, and thus every time gdb reads it with bfd,
>it issues these warnings in symfile.c:syms_from_objfile().
>
>When using the plain gdb front-end, stdout and stderr have been
>conveniently redirected to /dev/null by
>win32-nat.c:safe_symbol_file_add().  However, since Insight hooks
>warning() through gdbtk_warning(), it gets all messages and doesn't know
>to ignore them.  This patch just adds a regexp in gdbtk_tcl_warning to
>filter these messages.  I can think of cleaner solutions to doing this,
>such as having gdbtk_warning() check stdout/stderr, but it looks like
>this is the established way of doing things so here it is.

Cygwin really isn't doing anything terrifically special with its use of
.dbg, AFAIK.  So, it seems to me that, if this is fixed, it should be fixed
in a generic fashion so that everyone can benefit.

cgf

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

Christopher Faylor wrote:

> Cygwin really isn't doing anything terrifically special with its use of
> .dbg, AFAIK.  So, it seems to me that, if this is fixed, it should be fixed
> in a generic fashion so that everyone can benefit.

It's easy enough to change the regexp so that it matches any filename; I
had it only matching cygwin*.dbg just to be conservative.  The problem
then becomes that if there was ever a situation where this message was
legitimately desired, now you don't get it.  And by matching only
cygwin*.dbg, I carefully avoid the problem of not stepping on the toes
of other platforms that don't have this problem at all, where that
message might not be bogus.

Of course, the "generic fashion" already exists in the form of
win32-nat.c:safe_symbol_file_add(), which knows to turn off all warnings
and re-enable them again at the right place.  But this information is
never conveyed to the Insight frontend, so it's left to guess everything
based on regexps.

How about a patch that modifies gdbtk-hooks.c:gdbtk_warning() such that
instead of just blindly punting everything to gdbtk_tcl_warning(), it
first tries to check if stdout has been redirected to a null handle, and
just skip the warning if so?  That would let the exiting stuff in
win32-nat.c take care of suppressing these without any regexps.

Brian

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

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

Brian Dessent wrote:

> How about a patch that modifies gdbtk-hooks.c:gdbtk_warning() such that
> instead of just blindly punting everything to gdbtk_tcl_warning(), it
> first tries to check if stdout has been redirected to a null handle, and
> just skip the warning if so?  That would let the exiting stuff in
> win32-nat.c take care of suppressing these without any regexps.

See attached.

Brian

[-- Attachment #2: insight_suppress_warnings.patch --]
[-- Type: text/plain, Size: 956 bytes --]

2007-04-18  Brian Dessent  <brian@dessent.net>

	* generic/gdbtk-hooks.c (gdbtk_warning): Do not display warnings
	when output is currently suppressed.

Index: generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.41
diff -u -p -r1.41 gdbtk-hooks.c
--- generic/gdbtk-hooks.c	23 Dec 2005 18:23:16 -0000	1.41
+++ generic/gdbtk-hooks.c	18 Apr 2007 15:29:25 -0000
@@ -347,9 +347,15 @@ static void
 gdbtk_warning (const char *warning, va_list args)
 {
   char *buf;
-  xvasprintf (&buf, warning, args);
-  gdbtk_two_elem_cmd ("gdbtk_tcl_warning", buf);
-  free(buf);
+  
+  /* If gdb_stdout is currently attached to a null handle, do not display
+     the warning.  */
+  if (ui_file_data (gdb_stdout) != NULL)
+    {
+      xvasprintf (&buf, warning, args);
+      gdbtk_two_elem_cmd ("gdbtk_tcl_warning", buf);
+      free (buf);
+    }
 }
 
 

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

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

Brian Dessent wrote:

> > How about a patch that modifies gdbtk-hooks.c:gdbtk_warning() such that
> > instead of just blindly punting everything to gdbtk_tcl_warning(), it
> > first tries to check if stdout has been redirected to a null handle, and
> > just skip the warning if so?  That would let the exiting stuff in
> > win32-nat.c take care of suppressing these without any regexps.
> 
> See attached.

Arg, that won't work.  Simply checking ui_file_data (gdb_stdout) != NULL
is no good because even when gdb_stdout is not redirected its data
member can be NULL.  The only reliable way I could figure out to
determine if the stdout was redirected was to add an interface to
ui-file.c that checks if both the fputs and write functions were the
null functions.  See attached.

Brian

[-- Attachment #2: insight_suppress_warnings2.patch --]
[-- Type: text/plain, Size: 2311 bytes --]

gdb/
2007-04-18  Brian Dessent  <brian@dessent.net>

	* ui-file.c (ui_file_isnull): New function.
	* ui-file.h (ui_file_isnull): Add declaration.

gdb/gdbtk/
2007-04-18  Brian Dessent  <brian@dessent.net>

	* generic/gdbtk-hooks.c (gdbtk_warning): Do not process the warning
	if gdb_stdout has been redirected to a null handle.


Index: ui-file.c
===================================================================
RCS file: /cvs/src/src/gdb/ui-file.c,v
retrieving revision 1.13
diff -u -p -r1.13 ui-file.c
--- ui-file.c	9 Jan 2007 17:58:59 -0000	1.13
+++ ui-file.c	18 Apr 2007 16:34:59 -0000
@@ -166,6 +166,15 @@ ui_file_data (struct ui_file *file)
   return file->to_data;
 }
 
+int
+ui_file_isnull (struct ui_file *file)
+{
+  /* Return true if this handle has no output methods.  Used for checking 
+     if a handle has been temporarily redirected to suppress warnings.  */ 
+  return (file->to_fputs == null_file_fputs &&
+          file->to_write == null_file_write);
+}
+
 void
 gdb_flush (struct ui_file *file)
 {
Index: ui-file.h
===================================================================
RCS file: /cvs/src/src/gdb/ui-file.h,v
retrieving revision 1.6
diff -u -p -r1.6 ui-file.h
--- ui-file.h	9 Jan 2007 17:58:59 -0000	1.6
+++ ui-file.h	18 Apr 2007 16:34:59 -0000
@@ -59,6 +59,7 @@ extern void set_ui_file_data (struct ui_
 
 extern void *ui_file_data (struct ui_file *file);
 
+extern int ui_file_isnull (struct ui_file *file);
 
 extern void gdb_flush (struct ui_file *);
 
Index: gdbtk/generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.41
diff -u -p -r1.41 gdbtk-hooks.c
--- gdbtk/generic/gdbtk-hooks.c	23 Dec 2005 18:23:16 -0000	1.41
+++ gdbtk/generic/gdbtk-hooks.c	18 Apr 2007 16:34:59 -0000
@@ -347,9 +347,15 @@ static void
 gdbtk_warning (const char *warning, va_list args)
 {
   char *buf;
-  xvasprintf (&buf, warning, args);
-  gdbtk_two_elem_cmd ("gdbtk_tcl_warning", buf);
-  free(buf);
+  
+  /* If gdb_stdout is currently attached to a null handle, do not display
+     the warning.  */
+  if (!ui_file_isnull (gdb_stdout))
+    {
+      xvasprintf (&buf, warning, args);
+      gdbtk_two_elem_cmd ("gdbtk_tcl_warning", buf);
+      free (buf);
+    }
 }
 
 

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Christopher Faylor]

On Wed, Apr 18, 2007 at 08:19:44AM -0700, Brian Dessent wrote:
>Christopher Faylor wrote:
>
>> Cygwin really isn't doing anything terrifically special with its use of
>> .dbg, AFAIK.  So, it seems to me that, if this is fixed, it should be fixed
>> in a generic fashion so that everyone can benefit.
>
>It's easy enough to change the regexp so that it matches any filename; I
>had it only matching cygwin*.dbg just to be conservative.  The problem
>then becomes that if there was ever a situation where this message was
>legitimately desired, now you don't get it.  And by matching only
>cygwin*.dbg, I carefully avoid the problem of not stepping on the toes
>of other platforms that don't have this problem at all, where that
>message might not be bogus.
>
>Of course, the "generic fashion" already exists in the form of
>win32-nat.c:safe_symbol_file_add(), which knows to turn off all warnings
>and re-enable them again at the right place.  But this information is
>never conveyed to the Insight frontend, so it's left to guess everything
>based on regexps.
>
>How about a patch that modifies gdbtk-hooks.c:gdbtk_warning() such that
>instead of just blindly punting everything to gdbtk_tcl_warning(), it
>first tries to check if stdout has been redirected to a null handle, and
>just skip the warning if so?  That would let the exiting stuff in
>win32-nat.c take care of suppressing these without any regexps.

I wonder if there is just something being missed here.  The cygwin1.dbg
stuff was adapted from linux.  It is the mechanism used by Red Hat to
create debuginfo rpms.  If this isn't working in insight is there
something not quite right in gdb itself?  Or is the cygwin .dbg procedure
not putting some crucial information into the .dbg file?  I did have to
make some concessions to PE when I created that file since the standard
linux method didn't work quite right.

cgf

Re: [patch] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

Christopher Faylor wrote:

> I wonder if there is just something being missed here.  The cygwin1.dbg
> stuff was adapted from linux.  It is the mechanism used by Red Hat to
> create debuginfo rpms.  If this isn't working in insight is there
> something not quite right in gdb itself?  Or is the cygwin .dbg procedure
> not putting some crucial information into the .dbg file?  I did have to
> make some concessions to PE when I created that file since the standard
> linux method didn't work quite right.

What does objdump -h say for one of those Red Hat debug files?  Is there
a .text section and/or a section marked loadable?  I mean, I suppose we
could stick a dummy .text section in the .dbg file if it will shut up
gdb, but that sounds just as hacky as teaching gdb to properly suppress
its warnings.  I went over symfile.c:syms_from_objfile() again and all I
can really conclude is that if gdb doesn't warn when loading a Red Hat
debug file (which obviously it doesn't), then one of the following must
be true:

- it's being loaded with some other completely different mechanism
elsewhere (doesn't seem likely as the .gnu_debuglink code is right
there)
- the linux debug file has a .text section
- the linux port successfully supresses the warnings from being
displayed in all cases

Brian

[patch ping] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

[ Added gdb-patches@ since the revised patch touches files outside of
gdbtk/.  See <http://sourceware.org/ml/insight/2007-q2/msg00016.html>
for context. ]

Brian Dessent wrote:

> > > How about a patch that modifies gdbtk-hooks.c:gdbtk_warning() such that
> > > instead of just blindly punting everything to gdbtk_tcl_warning(), it
> > > first tries to check if stdout has been redirected to a null handle, and
> > > just skip the warning if so?  That would let the exiting stuff in
> > > win32-nat.c take care of suppressing these without any regexps.
> >
> > See attached.
> 
> Arg, that won't work.  Simply checking ui_file_data (gdb_stdout) != NULL
> is no good because even when gdb_stdout is not redirected its data
> member can be NULL.  The only reliable way I could figure out to
> determine if the stdout was redirected was to add an interface to
> ui-file.c that checks if both the fputs and write functions were the
> null functions.  See attached.

Ping?  Comments?

> ------------------------------------------------------------------------
> gdb/
> 2007-04-18  Brian Dessent  <brian@dessent.net>
> 
>         * ui-file.c (ui_file_isnull): New function.
>         * ui-file.h (ui_file_isnull): Add declaration.
> 
> gdb/gdbtk/
> 2007-04-18  Brian Dessent  <brian@dessent.net>
> 
>         * generic/gdbtk-hooks.c (gdbtk_warning): Do not process the warning
>         if gdb_stdout has been redirected to a null handle.
>

Re: [patch ping^2] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

Brian Dessent wrote:

> > gdb/
> > 2007-04-18  Brian Dessent  <brian@dessent.net>
> >
> >         * ui-file.c (ui_file_isnull): New function.
> >         * ui-file.h (ui_file_isnull): Add declaration.
> >
> > gdb/gdbtk/
> > 2007-04-18  Brian Dessent  <brian@dessent.net>
> >
> >         * generic/gdbtk-hooks.c (gdbtk_warning): Do not process the warning
> >         if gdb_stdout has been redirected to a null handle.
> >

Patch here: http://sourceware.org/ml/insight/2007-q2/msg00020.html

Can anyone please take a look at this?  Using insight on Cygwin without
this is a very frustrating affair which involves having to dismiss *two*
stupid focus-stealing pop-up dialogs every single time you type 'run'.

Brian

Re: [patch ping^2] suppress annoying warnings about cygwin1.dbg

[Pedro Alves]

Hi Brian,

Brian Dessent wrote:
> Patch here: http://sourceware.org/ml/insight/2007-q2/msg00020.html
> 
> Can anyone please take a look at this?  Using insight on Cygwin without
> this is a very frustrating affair which involves having to dismiss *two*
> stupid focus-stealing pop-up dialogs every single time you type 'run'.
> 

I can't test it right now, but,

Doesn't that warning about the missing .text section come from
win32-nat.c falling back to .text to compute the relocation
offsets, and not finding any .text section?

I think the changes to make win32 use solib-target.c at least will
turn this into a different warning, if they don't remove it.  I'm
not familiar with the  separate debug info mechanism in gdb, but to
me it sounds we should understand the reasons for the warnings and
fix it there.   I mean, why is it that these warnings don't happen
on other targets?  Why is gdb looking for loadable sections in a
debug info only file?

Cheers,
Pedro Alves

Re: [patch ping^2] suppress annoying warnings about cygwin1.dbg

[Daniel Jacobowitz]

On Tue, Jun 26, 2007 at 12:20:13AM +0100, Pedro Alves wrote:
> I think the changes to make win32 use solib-target.c at least will
> turn this into a different warning, if they don't remove it.  I'm
> not familiar with the  separate debug info mechanism in gdb, but to
> me it sounds we should understand the reasons for the warnings and
> fix it there.   I mean, why is it that these warnings don't happen
> on other targets?  Why is gdb looking for loadable sections in a
> debug info only file?

There are loadable sections in an ELF debug-only file; they all have
type NOBITS instead of PROGBITS, but are otherwise unchanged.  I'm
going to make a wild guess here that says you can't do that in
PE-COFF, so the text section is actually missing.  So probably we
should figure out whether we're loading a debug-info-only file at this
point, and not issue those warnings.  Or else remove the warnings
entirely.

The redirection to /dev/null is silly and should go away, by the way,
so relying on it isn't the right fix.  I don't remember if my recently
posted WIP patch removed it.  I think it did for most but not all
cases.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch ping^2] suppress annoying warnings about cygwin1.dbg

[Brian Dessent]

Daniel Jacobowitz wrote:

> There are loadable sections in an ELF debug-only file; they all have
> type NOBITS instead of PROGBITS, but are otherwise unchanged.  I'm
> going to make a wild guess here that says you can't do that in
> PE-COFF, so the text section is actually missing.  So probably we
> should figure out whether we're loading a debug-info-only file at this
> point, and not issue those warnings.  Or else remove the warnings
> entirely.

Ah, wish I'd known that at the time:
<http://sourceware.org/ml/insight/2007-q2/msg00022.html>

So, the proper way then would be to set some flag if we're reading a
.gnu-debuglink file and not generate the warnings in the first place?  I
can try to come up with something along those lines then.

> The redirection to /dev/null is silly and should go away, by the way,
> so relying on it isn't the right fix.  I don't remember if my recently

Right, it always looked pretty ugly to me, but when I initially started
looking at this I just wanted insight to shut the **** up.

Brian

Re: [patch ping^2] suppress annoying warnings about cygwin1.dbg

[Daniel Jacobowitz]

On Mon, Jun 25, 2007 at 05:53:19PM -0700, Brian Dessent wrote:
> Ah, wish I'd known that at the time:
> <http://sourceware.org/ml/insight/2007-q2/msg00022.html>

Sorry, I don't read the Insight list.

> So, the proper way then would be to set some flag if we're reading a
> .gnu-debuglink file and not generate the warnings in the first place?  I
> can try to come up with something along those lines then.

Either that, or just eliminate the warnings entirely.  Are they ever
really useful?

-- 
Daniel Jacobowitz
CodeSourcery

syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Brian Dessent]

Daniel Jacobowitz wrote:

> The redirection to /dev/null is silly and should go away, by the way,
> so relying on it isn't the right fix.  I don't remember if my recently
> posted WIP patch removed it.  I think it did for most but not all
> cases.

So I tried simply removing the two problematic warnings in
syms_from_objfile(), and then getting rid of the hacky
safe_symbol_file_add() wrapper in win32-nat.c.  This obviously has the
desired effect of not seeing the popups in insight, but now gdb has
become much more chatty.  This is what happens when you run a Hello
World program:

$ /build/combined/gdb/gdb --quiet hello
Reading symbols from /tmp/hello.exe...done.
(gdb) start
Reading in symbols for /home/brian/hello.c...done.
Breakpoint 1 at 0x401065: file /home/brian/hello.c, line 4.
Reading symbols from /winxp/system32/ntdll.dll...Minimal symbols from
ntdll.dll...done.
Reading symbols from /winxp/system32/kernel32.dll...Minimal symbols from
KERNEL32.dll...done.
Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
/usr/bin/cygwin1.dbg...done.
done.
Reading symbols from /winxp/system32/advapi32.dll...Minimal symbols from
ADVAPI32.dll...done.
Reading symbols from /winxp/system32/rpcrt4.dll...Minimal symbols from
RPCRT4.dll...done.
Reading symbols from /winxp/system32/shimeng.dll...
Minimal symbols from ShimEng.dll...done.
Reading symbols from /winxp/system32/secur32.dll...Minimal symbols from
Secur32.dll...done.
[New thread 1988.0xa1c]
Reading symbols from /winxp/system32/user32.dll...Minimal symbols from
USER32.dll...done.
Reading symbols from /winxp/system32/gdi32.dll...Minimal symbols from
GDI32.dll...done.
main (argc=1, 
    argv=0x662740) at /home/brian/hello.c:4
4       {
(gdb) c
Hello world!
Reading symbols from /winxp/system32/psapi.dll...Minimal symbols from
PSAPI.DLL...done.

Program exited normally.
(gdb) 

In insight, it's somewhat better because the "Reading symbols from %s"
messages are suppressed due to the hooks, but not the "Minimal symbols
from %s", with the result in the console of:

(gdb) start
Reading in symbols for /home/brian/hello.c...done.
Breakpoint 1 at 0x401065: file /home/brian/hello.c, line 4.
Minimal symbols from ntdll.dll...Minimal symbols from
KERNEL32.dll...Minimal symbols from ADVAPI32.dll...Minimal symbols from
RPCRT4.dll...Minimal symbols from ShimEng.dll...Minimal symbols from
Secur32.dll...[New thread 3520.0xa5c]
Minimal symbols from USER32.dll...Minimal symbols from GDI32.dll...main
(argc=2, argv=0x662980) at /home/brian/hello.c:4

(gdb) c
[Deleting thread 3520.0xa5c]
Minimal symbols from PSAPI.DLL...
Program exited normally.

(gdb)

For comparison, the output of current unmodified stock CVS gdb is:

$ /build/combined/gdb/gdb --quiet hello
Reading symbols from /tmp/hello.exe...done.
(gdb) start
Reading in symbols for /home/brian/hello.c...done.
Breakpoint 1 at 0x401065: file /home/brian/hello.c, line 4.
[New thread 3256.0xdc]
main (argc=1, 
    argv=0x662740) at /home/brian/hello.c:4
4       {
(gdb) c
Hello world!

Program exited normally.
(gdb)

Obviously (?) this is way too much spew, so if we want to eliminate the
hacky IO redirection, what's the way forward?  It seems to me that the
"Minimal symbols from %s.." (coff-pe-read.c:read_pe_exported_syms()) is
pure noise, so it could just be eliminated.  However, how do we gate the
output of "Reading in symbols for %s" so that it shows for the user's
objects but not for the dozens of system DLLs?  Is there an existing API
for this?  I gather the answer is no, otherwise the hacky IO redirection
stuff would have never been done.  Or do we just say that we shouldn't
try to filter these messages and let the user see them all?  The result
of *that* looks like this:

$ /build/combined/gdb/gdb --quiet hello
Reading symbols from /tmp/hello.exe...done.
(gdb) start
Reading in symbols for /home/brian/hello.c...done.
Breakpoint 1 at 0x401065: file /home/brian/hello.c, line 4.
Reading symbols from /winxp/system32/ntdll.dll...done.
Reading symbols from /winxp/system32/kernel32.dll...done.
Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
/usr/bin/cygwin1.dbg...done.
done.
Reading symbols from /winxp/system32/advapi32.dll...done.
Reading symbols from /winxp/system32/rpcrt4.dll...done.
Reading symbols from /winxp/system32/shimeng.dll...done.
Reading symbols from /winxp/system32/secur32.dll...done.
[New thread 3084.0x968]
Reading symbols from /winxp/system32/user32.dll...done.
Reading symbols from /winxp/system32/gdi32.dll...done.
main (argc=1, argv=0x662740) at /home/brian/hello.c:4
4       {
(gdb) c
Hello world!
Reading symbols from /winxp/system32/psapi.dll...done.
[Deleting thread 3084.0x968]

Program exited normally.
(gdb) quit

Again, this is for a trivial program that contains one call to puts()
and nothing else.  For a less trivial example, you can get dozens of
these as there are potentially many DLLs get loaded during the lifetime
of the app, and so it can be somewhat spammy.

Ideas?

Brian

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Daniel Jacobowitz]

On Wed, Jun 27, 2007 at 09:53:04PM -0700, Brian Dessent wrote:
> So I tried simply removing the two problematic warnings in
> syms_from_objfile(), and then getting rid of the hacky
> safe_symbol_file_add() wrapper in win32-nat.c.  This obviously has the
> desired effect of not seeing the popups in insight, but now gdb has
> become much more chatty.  This is what happens when you run a Hello
> World program:

Yes, sorry.  You'll want to hold on to that patch a little while, if
you can.  My Windows shared library patches fix both sets of extra
messages.

-- 
Daniel Jacobowitz
CodeSourcery

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Daniel Jacobowitz]

On Thu, Jun 28, 2007 at 06:46:01AM -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 27, 2007 at 09:53:04PM -0700, Brian Dessent wrote:
> > So I tried simply removing the two problematic warnings in
> > syms_from_objfile(), and then getting rid of the hacky
> > safe_symbol_file_add() wrapper in win32-nat.c.  This obviously has the
> > desired effect of not seeing the popups in insight, but now gdb has
> > become much more chatty.  This is what happens when you run a Hello
> > World program:
> 
> Yes, sorry.  You'll want to hold on to that patch a little while, if
> you can.  My Windows shared library patches fix both sets of extra
> messages.

Hi Brian,

The patch I was talking about has since been committed.  I don't
remember if that was supposed to fix Insight or supposed to allow
some nicer patch to do it... could you let me know if there's still a
problem in GDB 6.7 / HEAD?

-- 
Daniel Jacobowitz
CodeSourcery

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Brian Dessent]

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

Daniel Jacobowitz wrote:

> The patch I was talking about has since been committed.  I don't
> remember if that was supposed to fix Insight or supposed to allow
> some nicer patch to do it... could you let me know if there's still a
> problem in GDB 6.7 / HEAD?

Unfortunately, current HEAD is nearly unusable right now on Cygwin. 
This is a simple hello world program:

$ /build/combined/gdb/gdb hello
GNU gdb 6.7.50-20071012-cvs
Copyright (C) 2007 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-pc-cygwin"...
Reading symbols from /home/brian/hello.exe...done.
(gdb) start
Reading in symbols for hello.c...done.
Reading in symbols for hello.c...done.
Breakpoint 1 at 0x401065: file hello.c, line 4.
Reading symbols from /winxp/system32/ntdll.dll...done.
Reading symbols from /winxp/system32/kernel32.dll...done.
Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
/usr/bin/cygwin1.dbg...warning: no loadable sections found in added
symbol-file /usr/bin/cygwin1.dbg
warning: section .text not found in /usr/bin/cygwin1.dbg
warning: section .autoload_text not found in /usr/bin/cygwin1.dbg
warning: section .data not found in /usr/bin/cygwin1.dbg
warning: section .rdata not found in /usr/bin/cygwin1.dbg
warning: section .bss not found in /usr/bin/cygwin1.dbg
warning: section .edata not found in /usr/bin/cygwin1.dbg
warning: section .rsrc not found in /usr/bin/cygwin1.dbg
warning: section .reloc not found in /usr/bin/cygwin1.dbg
warning: section .cygwin_dll_common not found in /usr/bin/cygwin1.dbg
warning: section .idata not found in /usr/bin/cygwin1.dbg
warning: section .cygheap not found in /usr/bin/cygwin1.dbg
done.
done.
Reading symbols from /winxp/system32/advapi32.dll...done.
Reading symbols from /winxp/system32/rpcrt4.dll...done.
Reading symbols from /winxp/system32/secur32.dll...done.
Reading symbols from /winxp/system32/shimeng.dll...done.
[New thread 3872.0x95c]
Reading symbols from /winxp/system32/user32.dll...done.
Reading symbols from /winxp/system32/gdi32.dll...done.
main (argc=1, argv=0x6629f0) at hello.c:4
4       {

For comparison, with 6.5.50.20060706-cvs:

(gdb) start
Reading in symbols for hello.c...done.
Breakpoint 1 at 0x401065: file hello.c, line 4.
[New thread 4052.0xdb4]
main (argc=1, 
    argv=0x662cd0) at hello.c:4
4       {


If you do this in insight it's much worse as every one of those warnings
gets its own popup message box, which means twelve annoying things to
dismiss before you can even start to debug.  And on top of that, some of
these messages somehow end up spuriously appearing in with the program
display pane in insight (see attached PNG).  I guess there's some kind
of filter in the insight code that needs updating, but preferrably these
warnings shouldn't even be generated.

Brian

[-- Attachment #2: insight-reading-symbols.png --]
[-- Type: image/png, Size: 16056 bytes --]

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

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

Brian Dessent wrote:
> Daniel Jacobowitz wrote:
> 
> Unfortunately, current HEAD is nearly unusable right now on Cygwin. 

I shook a bit when I read "unusable" :)  That's a pretty strong word.

> If you do this in insight it's much worse as every one of those warnings
> gets its own popup message box, which means twelve annoying things to
> dismiss before you can even start to debug.  And on top of that, some of
> these messages somehow end up spuriously appearing in with the program
> display pane in insight (see attached PNG).  I guess there's some kind
> of filter in the insight code that needs updating, but preferrably these
> warnings shouldn't even be generated.
> 

I've had this fixed here for a while.  It goes on the direction of removing
the warnings, and removing the warning suppressing on win32-nat.c.  Could
you test it with cygwin1.dbg and with insight?

Cheers,
Pedro Alves


[-- Attachment #2: remove_redirect_null.diff --]
[-- Type: text/x-diff, Size: 4792 bytes --]

2007-10-09  Pedro Alves  <pedro_alves@portugalmail.pt>

	* symfile.c (syms_from_objfile): Don't warn if loadable
	sections are not found.

---
 gdb/symfile.c   |   29 +++++++++--------------
 gdb/win32-nat.c |   70 --------------------------------------------------------
 2 files changed, 13 insertions(+), 86 deletions(-)

Index: src/gdb/symfile.c
===================================================================
--- src.orig/gdb/symfile.c	2007-10-08 23:45:50.000000000 +0100
+++ src/gdb/symfile.c	2007-10-13 01:51:40.000000000 +0100
@@ -822,18 +822,18 @@ syms_from_objfile (struct objfile *objfi
 	bfd_map_over_sections (objfile->obfd, find_lowest_section,
 			       &lower_sect);
       if (lower_sect == NULL)
-	warning (_("no loadable sections found in added symbol-file %s"),
-		 objfile->name);
-      else
-	if ((bfd_get_section_flags (objfile->obfd, lower_sect) & SEC_CODE) == 0)
-	  warning (_("Lowest section in %s is %s at %s"),
-		   objfile->name,
-		   bfd_section_name (objfile->obfd, lower_sect),
-		   paddr (bfd_section_vma (objfile->obfd, lower_sect)));
-      if (lower_sect != NULL)
- 	lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
-      else
  	lower_offset = 0;
+      else
+	{
+	  int flags = bfd_get_section_flags (objfile->obfd, lower_sect);
+	  if (flags == 0)
+	    warning (_("Lowest section in %s is %s at %s"),
+		     objfile->name,
+		     bfd_section_name (objfile->obfd, lower_sect),
+		     paddr (bfd_section_vma (objfile->obfd, lower_sect)));
+
+	  lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
+	}
 
       /* Calculate offsets for the loadable sections.
  	 FIXME! Sections must be in order of increasing loadable section
@@ -860,12 +860,7 @@ syms_from_objfile (struct objfile *objfi
                     addrs->other[i].sectindex = sect->index ;
                   }
                 else
-                  {
-                    warning (_("section %s not found in %s"),
-                             addrs->other[i].name,
-                             objfile->name);
-                    addrs->other[i].addr = 0;
-                  }
+		  addrs->other[i].addr = 0;
               }
             else
               addrs->other[i].addr = lower_offset;
Index: src/gdb/win32-nat.c
===================================================================
--- src.orig/gdb/win32-nat.c	2007-10-13 01:51:10.000000000 +0100
+++ src/gdb/win32-nat.c	2007-10-13 01:51:40.000000000 +0100
@@ -525,19 +525,6 @@ failed:
   return 0;
 }
 
-/* Encapsulate the information required in a call to
-   symbol_file_add_args */
-struct safe_symbol_file_add_args
-{
-  char *name;
-  int from_tty;
-  struct section_addr_info *addrs;
-  int mainline;
-  int flags;
-  struct ui_file *err, *out;
-  struct objfile *ret;
-};
-
 /* Maintain a linked list of "so" information. */
 struct lm_info
 {
@@ -546,61 +533,6 @@ struct lm_info
 
 static struct so_list solib_start, *solib_end;
 
-/* Call symbol_file_add with stderr redirected.  We don't care if there
-   are errors. */
-static int
-safe_symbol_file_add_stub (void *argv)
-{
-#define p ((struct safe_symbol_file_add_args *) argv)
-  struct so_list *so = &solib_start;
-
-  p->ret = symbol_file_add (p->name, p->from_tty, p->addrs, p->mainline, p->flags);
-  return !!p->ret;
-#undef p
-}
-
-/* Restore gdb's stderr after calling symbol_file_add */
-static void
-safe_symbol_file_add_cleanup (void *p)
-{
-#define sp ((struct safe_symbol_file_add_args *)p)
-  gdb_flush (gdb_stderr);
-  gdb_flush (gdb_stdout);
-  ui_file_delete (gdb_stderr);
-  ui_file_delete (gdb_stdout);
-  gdb_stderr = sp->err;
-  gdb_stdout = sp->out;
-#undef sp
-}
-
-/* symbol_file_add wrapper that prevents errors from being displayed. */
-static struct objfile *
-safe_symbol_file_add (char *name, int from_tty,
-		      struct section_addr_info *addrs,
-		      int mainline, int flags)
-{
-  struct safe_symbol_file_add_args p;
-  struct cleanup *cleanup;
-
-  cleanup = make_cleanup (safe_symbol_file_add_cleanup, &p);
-
-  p.err = gdb_stderr;
-  p.out = gdb_stdout;
-  gdb_flush (gdb_stderr);
-  gdb_flush (gdb_stdout);
-  gdb_stderr = ui_file_new ();
-  gdb_stdout = ui_file_new ();
-  p.name = name;
-  p.from_tty = from_tty;
-  p.addrs = addrs;
-  p.mainline = mainline;
-  p.flags = flags;
-  catch_errors (safe_symbol_file_add_stub, &p, "", RETURN_MASK_ERROR);
-
-  do_cleanups (cleanup);
-  return p.ret;
-}
-
 static struct so_list *
 win32_make_so (const char *name, DWORD load_addr)
 {
@@ -801,7 +733,7 @@ dll_symbol_command (char *args, int from
       args = newargs;
     }
 
-  safe_symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
+  symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
 }
 
 /* Handle DEBUG_STRING output from child process.

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Brian Dessent]

Pedro Alves wrote:

> I shook a bit when I read "unusable" :)  That's a pretty strong word.

I consider having to dismiss a dozen spurious popups every time I run
the inferior to be unusable.

> I've had this fixed here for a while.  It goes on the direction of removing
> the warnings, and removing the warning suppressing on win32-nat.c.  Could
> you test it with cygwin1.dbg and with insight?

I had something like this in my tree in the past and it does in fact
kill the popups in insight, but the regular gdb output is still a lot
more chatty than it used to be:

$ /build/combined/gdb/gdb hello
GNU gdb 6.7.50-20071012-cvs
Copyright (C) 2007 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-pc-cygwin"...
Reading symbols from /home/brian/hello.exe...done.
(gdb) start
Reading in symbols for hello.c...done.
Reading in symbols for hello.c...done.
Breakpoint 1 at 0x401065: file hello.c, line 4.
Reading symbols from /winxp/system32/ntdll.dll...done.
Reading symbols from /winxp/system32/kernel32.dll...done.
Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
/usr/bin/cygwin1.dbg...done.
done.
Reading symbols from /winxp/system32/advapi32.dll...done.
Reading symbols from /winxp/system32/rpcrt4.dll...done.
Reading symbols from /winxp/system32/secur32.dll...done.
Reading symbols from /winxp/system32/shimeng.dll...done.
[New thread 2816.0xa70]
Reading symbols from /winxp/system32/user32.dll...done.
Reading symbols from /winxp/system32/gdi32.dll...done.
main (argc=1, argv=0x6629f0) at hello.c:4
4       {
(gdb) n
5         puts ("Hello world!");
(gdb) n
6         return 0;
(gdb) n
7       }
(gdb) 
Reading in symbols for
/usr/src/sourceware/winsup/cygwin/dcrt0.cc...done.
Reading in symbols for
/usr/src/sourceware/winsup/cygwin/cygtls.cc...done.
Hello world!
Reading symbols from /winxp/system32/psapi.dll...done.

Program exited normally.
(gdb) quit

For these system DLLs that are not necessarily relevant to the user's
code it sort of feels rather spammy.

In insight the problem of "Reading symbols from ..." output screwing up
the source pane still exists, but I think that can be fixed with a tcl
regexp somewhere.

Brian

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

Brian Dessent wrote:
> I had something like this in my tree in the past and it does in fact
> kill the popups in insight, but the regular gdb output is still a lot
> more chatty than it used to be:
>
> $ /build/combined/gdb/gdb hello
> GNU gdb 6.7.50-20071012-cvs
> Copyright (C) 2007 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-pc-cygwin"...
> Reading symbols from /home/brian/hello.exe...done.
> (gdb) start
> Reading in symbols for hello.c...done.
> Reading in symbols for hello.c...done.
> Breakpoint 1 at 0x401065: file hello.c, line 4.
> Reading symbols from /winxp/system32/ntdll.dll...done.
> Reading symbols from /winxp/system32/kernel32.dll...done.
> Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from
> /usr/bin/cygwin1.dbg...done.
> done.
> Reading symbols from /winxp/system32/advapi32.dll...done.
> Reading symbols from /winxp/system32/rpcrt4.dll...done.
> Reading symbols from /winxp/system32/secur32.dll...done.
> Reading symbols from /winxp/system32/shimeng.dll...done.
> [New thread 2816.0xa70]
> Reading symbols from /winxp/system32/user32.dll...done.
> Reading symbols from /winxp/system32/gdi32.dll...done.
> main (argc=1, argv=0x6629f0) at hello.c:4
> 4       {
> (gdb) n
> 5         puts ("Hello world!");
> (gdb) n
> 6         return 0;
> (gdb) n
> 7       }
> (gdb)
> Reading in symbols for
> /usr/src/sourceware/winsup/cygwin/dcrt0.cc...done.
> Reading in symbols for
> /usr/src/sourceware/winsup/cygwin/cygtls.cc...done.
> Hello world!
> Reading symbols from /winxp/system32/psapi.dll...done.
>
> Program exited normally.
> (gdb) quit
>

Doesn't happen here.  Those messages should only show up when manually
adding a symbol file, or when extra verbosity is requested by the user.
Do you happen to have a "set verbose 1" in your .gdbinit file?

-- 
Cheers,
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Brian Dessent]

Pedro Alves wrote:

> Doesn't happen here.  Those messages should only show up when manually
> adding a symbol file, or when extra verbosity is requested by the user.
> Do you happen to have a "set verbose 1" in your .gdbinit file?

Well I'll be... yes, I did have that in a long-forgotten .gdbinit.  It
hadn't occurred to me that it was responsible since apparently the
verbose setting never caused that kind of spewage in prior versions.

So I think the section warnings in syms_from_objfile definitely need to
go and we can finally kill the hacky redirection in win32-nat.c per your
patch.  I still will look into fixing insight so that it doesn't
intermix "Reading symbols from ..." with the source code pane, but I
guess it's not as pressing since it's a non-default behavior.

Thanks,
Brian

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Daniel Jacobowitz]

On Sat, Oct 13, 2007 at 02:21:56AM +0100, Pedro Alves wrote:
>        if (lower_sect == NULL)
> -	warning (_("no loadable sections found in added symbol-file %s"),
> -		 objfile->name);
> -      else
> -	if ((bfd_get_section_flags (objfile->obfd, lower_sect) & SEC_CODE) == 0)
> -	  warning (_("Lowest section in %s is %s at %s"),
> -		   objfile->name,
> -		   bfd_section_name (objfile->obfd, lower_sect),
> -		   paddr (bfd_section_vma (objfile->obfd, lower_sect)));
> -      if (lower_sect != NULL)
> - 	lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
> -      else

Removing these warnings seems reasonable.  I'll be glad to be rid of
them on GNU/Linux too:

warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

> +      else
> +	{
> +	  int flags = bfd_get_section_flags (objfile->obfd, lower_sect);
> +	  if (flags == 0)
> +	    warning (_("Lowest section in %s is %s at %s"),
> +		     objfile->name,
> +		     bfd_section_name (objfile->obfd, lower_sect),
> +		     paddr (bfd_section_vma (objfile->obfd, lower_sect)));
> +
> +	  lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
> +	}

But why are you keeping this warning?  I'm not sure what flags == 0
checks, but it's very unlikely to be true; most sections will have
SEC_READONLY set.

> @@ -860,12 +860,7 @@ syms_from_objfile (struct objfile *objfi
>                      addrs->other[i].sectindex = sect->index ;
>                    }
>                  else
> -                  {
> -                    warning (_("section %s not found in %s"),
> -                             addrs->other[i].name,
> -                             objfile->name);
> -                    addrs->other[i].addr = 0;
> -                  }
> +		  addrs->other[i].addr = 0;
>                }
>              else
>                addrs->other[i].addr = lower_offset;

I know you needed this one before because win32-nat.c specified an
offset for .text manually.  I don't think it does so any more, though.
This one's useful, since you can provoke it with a typo:

(gdb) add-symbol-file cat 1000 -s .dataz 24
add symbol table from file "cat" at
        .text_addr = 0x3e8
        .dataz_addr = 0x18
(y or n) y
Reading symbols from /bin/cat...warning: section .dataz not found in /bin/cat

-- 
Daniel Jacobowitz
CodeSourcery

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

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

Daniel Jacobowitz wrote:
> On Sat, Oct 13, 2007 at 02:21:56AM +0100, Pedro Alves wrote:
>>        if (lower_sect == NULL)
>> -	warning (_("no loadable sections found in added symbol-file %s"),
>> -		 objfile->name);
>> -      else
>> -	if ((bfd_get_section_flags (objfile->obfd, lower_sect) & SEC_CODE) == 0)
>> -	  warning (_("Lowest section in %s is %s at %s"),
>> -		   objfile->name,
>> -		   bfd_section_name (objfile->obfd, lower_sect),
>> -		   paddr (bfd_section_vma (objfile->obfd, lower_sect)));
>> -      if (lower_sect != NULL)
>> - 	lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
>> -      else
> 
> Removing these warnings seems reasonable.  I'll be glad to be rid of
> them on GNU/Linux too:
> 
> warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4
> 
>> +      else
>> +	{
>> +	  int flags = bfd_get_section_flags (objfile->obfd, lower_sect);
>> +	  if (flags == 0)
>> +	    warning (_("Lowest section in %s is %s at %s"),
>> +		     objfile->name,
>> +		     bfd_section_name (objfile->obfd, lower_sect),
>> +		     paddr (bfd_section_vma (objfile->obfd, lower_sect)));
>> +
>> +	  lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
>> +	}
> 
> But why are you keeping this warning?  I'm not sure what flags == 0
> checks, but it's very unlikely to be true; most sections will have
> SEC_READONLY set.
> 

Blunder, it should have been:
+	  if ((flags & SEC_CODE)== 0)

to match this bit above:

-	if ((bfd_get_section_flags (objfile->obfd, lower_sect) & SEC_CODE) == 0)

which means I was trying to remove this warning:

-	warning (_("no loadable sections found in added symbol-file %s"),
-		 objfile->name);

but not touch that one:

> warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4

as it doesn't affect the cygwin1.dbg case, because there are no
code sections there.  Somehow I lost the '& SEC_CODE' in the
process.

>> @@ -860,12 +860,7 @@ syms_from_objfile (struct objfile *objfi
>>                      addrs->other[i].sectindex = sect->index ;
>>                    }
>>                  else
>> -                  {
>> -                    warning (_("section %s not found in %s"),
>> -                             addrs->other[i].name,
>> -                             objfile->name);
>> -                    addrs->other[i].addr = 0;
>> -                  }
>> +		  addrs->other[i].addr = 0;
>>                }
>>              else
>>                addrs->other[i].addr = lower_offset;
> 
> I know you needed this one before because win32-nat.c specified an
> offset for .text manually.  I don't think it does so any more, though.
> This one's useful, since you can provoke it with a typo:
> 
> (gdb) add-symbol-file cat 1000 -s .dataz 24
> add symbol table from file "cat" at
>         .text_addr = 0x3e8
>         .dataz_addr = 0x18
> (y or n) y
> Reading symbols from /bin/cat...warning: section .dataz not found in /bin/cat
> 

Ah, right, I clearly see that now.  I just more or less blindly
removed the warnings that were being output.

We do get that warning today, because the cygwin1.dbg file only
contains the debug info sections, but ADDRS is filled with
every SEC_ALLOC | SEC_LOAD section of cygwin1.dll.  Would it be
OK to only do the warning if VERBO (it is set to from_tty in
the case you mentioned) or info_verbose are on?

Cheers,
Pedro Alves

[-- Attachment #2: sepdebug_warnings.diff --]
[-- Type: text/x-diff, Size: 1903 bytes --]

2007-10-09  Pedro Alves  <pedro_alves@portugalmail.pt>

	* symfile.c (syms_from_objfile): Don't warn if loadable sections
	are not found.  Don't warn about which is the lowest section.
	Only warn about a section not being found if VERBO or
	info_verbose.  Turn that warning into a print_unfiltered.

---
 gdb/symfile.c |   16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

Index: src/gdb/symfile.c
===================================================================
--- src.orig/gdb/symfile.c	2007-10-28 22:57:49.000000000 +0000
+++ src/gdb/symfile.c	2007-10-29 00:09:34.000000000 +0000
@@ -821,15 +821,6 @@ syms_from_objfile (struct objfile *objfi
       if (lower_sect == NULL)
 	bfd_map_over_sections (objfile->obfd, find_lowest_section,
 			       &lower_sect);
-      if (lower_sect == NULL)
-	warning (_("no loadable sections found in added symbol-file %s"),
-		 objfile->name);
-      else
-	if ((bfd_get_section_flags (objfile->obfd, lower_sect) & SEC_CODE) == 0)
-	  warning (_("Lowest section in %s is %s at %s"),
-		   objfile->name,
-		   bfd_section_name (objfile->obfd, lower_sect),
-		   paddr (bfd_section_vma (objfile->obfd, lower_sect)));
       if (lower_sect != NULL)
  	lower_offset = bfd_section_vma (objfile->obfd, lower_sect);
       else
@@ -861,9 +852,10 @@ syms_from_objfile (struct objfile *objfi
                   }
                 else
                   {
-                    warning (_("section %s not found in %s"),
-                             addrs->other[i].name,
-                             objfile->name);
+                    if (verbo || info_verbose)
+                      printf_unfiltered (_("section %s not found in %s\n"),
+                                         addrs->other[i].name,
+                                         objfile->name);
                     addrs->other[i].addr = 0;
                   }
               }

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

Pedro Alves wrote:
> -       warning (_("no loadable sections found in added symbol-file %s"),
> -                objfile->name);
>
> but not touch that one:
>
> > warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at ffffe0b4
>
> as it doesn't affect the cygwin1.dbg case, because there are no
> code sections there.  Somehow I lost the '& SEC_CODE' in the
> process.
>

> >> -                    warning (_("section %s not found in %s"),
> >> -                             addrs->other[i].name,
> >> -                             objfile->name);

> >
> > I know you needed this one before because win32-nat.c specified an
> > offset for .text manually.  I don't think it does so any more, though.
> > This one's useful, since you can provoke it with a typo:
> >
> > (gdb) add-symbol-file cat 1000 -s .dataz 24
> > add symbol table from file "cat" at
> >         .text_addr = 0x3e8
> >         .dataz_addr = 0x18
> > (y or n) y
> > Reading symbols from /bin/cat...warning: section .dataz not found in /bin/cat
> >
>
> Ah, right, I clearly see that now.  I just more or less blindly
> removed the warnings that were being output.
>

> We do get that warning today, because the cygwin1.dbg file only
> contains the debug info sections, but ADDRS is filled with
> every SEC_ALLOC | SEC_LOAD section of cygwin1.dll.  Would it be
> OK to only do the warning if VERBO (it is set to from_tty in
> the case you mentioned) or info_verbose are on?
>

I failed to mention that this patch wouldn't remove the need to the
safe_symbol_file_add stderr redirection hack in win32-nat.c, as
will that warning will be hit when using  the dll_symbol_command
or add-symbol-file to load dll symbols from an object with seperate
debug info manually, but should be seen as an "incremental" fix
as a more correct solution is devised.

OK, so, on to fix this properly to remove that hack completelly.

Can anyone point me into why the non-debug sections are
preserved (as NOBITS) in the seperate debug file?
Could it be so support the case where the section headers
were stripped in the main file?
To help if there are relocs against section symbols in
the debug info?  Not sure if that makes sense in
a NOBITS section.
Or, are they added so to keep tools that currently expect
them there happy?

If they're really needed, we should then be fixing the
format instead.  If it isn't possible to emulate the NOBITS
funcionality with real sections, I think we can add a new
section to the seperate debug info file, that bfd parses
to make fake NOBITS pseudo sections (much like core file
pseudo sections).  Or maybe special casing PE/coff
support in gdb would be easier, but I don't know if other
tools expect them.

If they're not really needed, then the shortest change would be to
not pass orig_addrs to symbol_file_add
in symfile.c:symbol_file_add_with_addrs_or_offsets.

static struct objfile *
symbol_file_add_with_addrs_or_offsets (bfd *abfd, int from_tty,
                                       struct section_addr_info *addrs,
                                       struct section_offsets *offsets,
                                       int num_offsets,
                                       int mainline, int flags)
{

 struct section_addr_info *orig_addrs = NULL;

(...)

 if (addrs)
    {
      orig_addrs = copy_section_addr_info (addrs);
      make_cleanup_free_section_addr_info (orig_addrs);
    }

(...)

  if (objfile->psymtabs == NULL)
    debugfile = find_separate_debug_file (objfile);
  if (debugfile)
    {
      if (addrs != NULL)
        {
          objfile->separate_debug_objfile
            = symbol_file_add (debugfile, from_tty, orig_addrs, 0, flags);
        }
      else
        {
          objfile->separate_debug_objfile
            = symbol_file_add (debugfile, from_tty, NULL, 0, flags);
        }
      objfile->separate_debug_objfile->separate_debug_objfile_backlink
        = objfile;

(...)
}

I'm sure the sections are preserved for a reason, but what is it?

Cheers,
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Daniel Jacobowitz]

On Mon, Oct 29, 2007 at 09:03:08AM +0000, Pedro Alves wrote:
> Can anyone point me into why the non-debug sections are
> preserved (as NOBITS) in the seperate debug file?
> Could it be so support the case where the section headers
> were stripped in the main file?
> To help if there are relocs against section symbols in
> the debug info?  Not sure if that makes sense in
> a NOBITS section.
> Or, are they added so to keep tools that currently expect
> them there happy?

I don't think you can do without them, because you have a symbol table
in the separate file; the symbol table needs to say which section each
symbol is defined in.  But I'm just extrapolating this from what I
know about ELF.  What I know about PE/COFF wouldn't fill a teacup.

If the symbol table doesn't exist in the original file, and you
don't load the debug file with the right offsets, the symbols aren't
going to be found at the correct addresses.

I haven't looked at your previous message yet - I'll try to today.

-- 
Daniel Jacobowitz
CodeSourcery

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

I'm a bit puzzled, since I've just found out that:

strip --strip-debug ${dest} -o ${stripped_file}
strip --only-keep-debug main.exe -o ${debug_file}
objcopy --add-gnu-debuglink=${debug_file} ${stripped_file} ${dest}

... currently plays nicelly in PE/coff + stabs+.  The
CONTENTS | ALLOC sections simply get
the CONTENTS dropped, thus it seems that gdb
doesn't need any fixing after all.

>objdump.exe -h main.exe

main.exe:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         000003a0  00401000  00401000  00000400  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00100000  00402000  00402000  00000800  2**4
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000040  00502000  00502000  00000000  2**4
                   ALLOC
   3 .idata        00000170  00503000  00503000  00100800  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   4 .gnu_debuglink 00000014  00504000  00504000  00100a00  2**2
                   CONTENTS, READONLY, DEBUGGING

>objdump.exe -h main.exe.dbg

main.exe.dbg:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         000003a0  00401000  00401000  00000000  2**4
                   ALLOC, LOAD, READONLY, CODE
   1 .data         00100000  00402000  00402000  00000000  2**4
                   ALLOC, LOAD, DATA
   2 .bss          00000040  00502000  00502000  00000000  2**4
                   ALLOC
   3 .idata        00000170  00503000  00503000  00000000  2**2
                   ALLOC, LOAD, DATA
   4 .stab         0000c630  00504000  00504000  00000268  2**2
                   CONTENTS, READONLY, DEBUGGING, EXCLUDE
   5 .stabstr      0004e99f  00511000  00511000  0000ca68  2**0
                   CONTENTS, READONLY, DEBUGGING, EXCLUDE


Chris, Brian, would it be possible to instead fix the
cygwin1.dbg generation to do something similar to
the above recipe?

I'm posting a few patches to enable sepdebug.exp and
sepsymtab.exp testing on Cygwin.

I've also locally hacked shreloc.exp to generate seperate
debug info to test shared objects, and relocation, as
that isn't currently tested by sepdebug.exp.  It worked
fine.

This means the patches upthread are withdrawn
for now.

Cheers,
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Christopher Faylor]

On Mon, Oct 29, 2007 at 08:33:18AM -0400, Daniel Jacobowitz wrote:
>On Mon, Oct 29, 2007 at 09:03:08AM +0000, Pedro Alves wrote:
>> Can anyone point me into why the non-debug sections are
>> preserved (as NOBITS) in the seperate debug file?
>> Could it be so support the case where the section headers
>> were stripped in the main file?
>> To help if there are relocs against section symbols in
>> the debug info?  Not sure if that makes sense in
>> a NOBITS section.
>> Or, are they added so to keep tools that currently expect
>> them there happy?
>
>I don't think you can do without them, because you have a symbol table
>in the separate file; the symbol table needs to say which section each
>symbol is defined in.  But I'm just extrapolating this from what I
>know about ELF.  What I know about PE/COFF wouldn't fill a teacup.

It should be equivalent in PE/COFF, IIRC.

cgf

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Christopher Faylor]

On Mon, Oct 29, 2007 at 10:53:20PM +0000, Pedro Alves wrote:
> I'm a bit puzzled, since I've just found out that:
>
> strip --strip-debug ${dest} -o ${stripped_file}
> strip --only-keep-debug main.exe -o ${debug_file}
> objcopy --add-gnu-debuglink=${debug_file} ${stripped_file} ${dest}
>
> ... currently plays nicelly in PE/coff + stabs+.  The
> CONTENTS | ALLOC sections simply get
> the CONTENTS dropped, thus it seems that gdb
> doesn't need any fixing after all.
>
>> objdump.exe -h main.exe
>
> main.exe:     file format pei-i386
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         000003a0  00401000  00401000  00000400  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         00100000  00402000  00402000  00000800  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .bss          00000040  00502000  00502000  00000000  2**4
>                   ALLOC
>   3 .idata        00000170  00503000  00503000  00100800  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   4 .gnu_debuglink 00000014  00504000  00504000  00100a00  2**2
>                   CONTENTS, READONLY, DEBUGGING
>
>> objdump.exe -h main.exe.dbg
>
> main.exe.dbg:     file format pei-i386
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         000003a0  00401000  00401000  00000000  2**4
>                   ALLOC, LOAD, READONLY, CODE
>   1 .data         00100000  00402000  00402000  00000000  2**4
>                   ALLOC, LOAD, DATA
>   2 .bss          00000040  00502000  00502000  00000000  2**4
>                   ALLOC
>   3 .idata        00000170  00503000  00503000  00000000  2**2
>                   ALLOC, LOAD, DATA
>   4 .stab         0000c630  00504000  00504000  00000268  2**2
>                   CONTENTS, READONLY, DEBUGGING, EXCLUDE
>   5 .stabstr      0004e99f  00511000  00511000  0000ca68  2**0
>                   CONTENTS, READONLY, DEBUGGING, EXCLUDE
>
>
> Chris, Brian, would it be possible to instead fix the
> cygwin1.dbg generation to do something similar to
> the above recipe?

No need to ask anyone.  Just make the changes you're proposing and see
if they work.

cgf

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

Christopher Faylor wrote:
> > Chris, Brian, would it be possible to instead fix the
> > cygwin1.dbg generation to do something similar to
> > the above recipe?
>
> No need to ask anyone.  Just make the changes you're proposing and see
> if they work.
>

Language barrier, I guess.   I was not asking for you to do it.  I was trying to
ask if you foresee any problems in doing it, since you were the one who
wrote the dllfixdbg thing.  The "ask before you spend a bunch of time in
it for nothing" theme.

I'll see if I can test it in a few days...

Cheers,
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

Hi all,

The cygwin1.dbg (the cygwin1.dll separate debug info file)
generation has now been been fixed to keep the section info of
non-debug sections, so the warnings [1] will not happen
anymore starting from the next cygwin snapshot.

[1] http://www.cygwin.com/ml/insight/2007-q2/msg00016.html

Is there anything else preventing us from removing the
stderr -> null redirection from win32-nat.c ?

The redirection is only done on the "dll-symbols"
command, and adding cygwin1.dll manually isn't
a common use case, I guess.

Notice that the cygwin1.dbg generation is special.
Everyone else should be using the recipe I posted in
a previous message, which produces files that don't
trigger those warnings.

-- 
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

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

Pedro Alves wrote:
> 
> Is there anything else preventing us from removing the
> stderr -> null redirection from win32-nat.c ?
> 

Like so ?

-- 
Cheers,
Pedro Alves


[-- Attachment #2: remove_redirect_null.diff --]
[-- Type: text/x-diff, Size: 2938 bytes --]

2007-11-08  Pedro Alves  <pedro_alves@portugalmail.pt>

	* win32-nat.c (safe_symbol_file_add_args,
	safe_symbol_file_add_stub, safe_symbol_file_add_cleanup)
	(safe_symbol_file_add): Remove.
	(dll_symbol_command): Call symbol_file_add directly.

---
 gdb/win32-nat.c |   70 --------------------------------------------------------
 1 file changed, 1 insertion(+), 69 deletions(-)

Index: src/gdb/win32-nat.c
===================================================================
--- src.orig/gdb/win32-nat.c	2007-11-08 23:12:36.000000000 +0000
+++ src/gdb/win32-nat.c	2007-11-08 23:12:40.000000000 +0000
@@ -527,19 +527,6 @@ failed:
   return 0;
 }
 
-/* Encapsulate the information required in a call to
-   symbol_file_add_args */
-struct safe_symbol_file_add_args
-{
-  char *name;
-  int from_tty;
-  struct section_addr_info *addrs;
-  int mainline;
-  int flags;
-  struct ui_file *err, *out;
-  struct objfile *ret;
-};
-
 /* Maintain a linked list of "so" information. */
 struct lm_info
 {
@@ -548,61 +535,6 @@ struct lm_info
 
 static struct so_list solib_start, *solib_end;
 
-/* Call symbol_file_add with stderr redirected.  We don't care if there
-   are errors. */
-static int
-safe_symbol_file_add_stub (void *argv)
-{
-#define p ((struct safe_symbol_file_add_args *) argv)
-  struct so_list *so = &solib_start;
-
-  p->ret = symbol_file_add (p->name, p->from_tty, p->addrs, p->mainline, p->flags);
-  return !!p->ret;
-#undef p
-}
-
-/* Restore gdb's stderr after calling symbol_file_add */
-static void
-safe_symbol_file_add_cleanup (void *p)
-{
-#define sp ((struct safe_symbol_file_add_args *)p)
-  gdb_flush (gdb_stderr);
-  gdb_flush (gdb_stdout);
-  ui_file_delete (gdb_stderr);
-  ui_file_delete (gdb_stdout);
-  gdb_stderr = sp->err;
-  gdb_stdout = sp->out;
-#undef sp
-}
-
-/* symbol_file_add wrapper that prevents errors from being displayed. */
-static struct objfile *
-safe_symbol_file_add (char *name, int from_tty,
-		      struct section_addr_info *addrs,
-		      int mainline, int flags)
-{
-  struct safe_symbol_file_add_args p;
-  struct cleanup *cleanup;
-
-  cleanup = make_cleanup (safe_symbol_file_add_cleanup, &p);
-
-  p.err = gdb_stderr;
-  p.out = gdb_stdout;
-  gdb_flush (gdb_stderr);
-  gdb_flush (gdb_stdout);
-  gdb_stderr = ui_file_new ();
-  gdb_stdout = ui_file_new ();
-  p.name = name;
-  p.from_tty = from_tty;
-  p.addrs = addrs;
-  p.mainline = mainline;
-  p.flags = flags;
-  catch_errors (safe_symbol_file_add_stub, &p, "", RETURN_MASK_ERROR);
-
-  do_cleanups (cleanup);
-  return p.ret;
-}
-
 static struct so_list *
 win32_make_so (const char *name, DWORD load_addr)
 {
@@ -806,7 +738,7 @@ dll_symbol_command (char *args, int from
       args = newargs;
     }
 
-  safe_symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
+  symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
 }
 
 /* Handle DEBUG_STRING output from child process.

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Christopher Faylor]

On Thu, Nov 08, 2007 at 11:48:41PM +0000, Pedro Alves wrote:
> Pedro Alves wrote:
>> Is there anything else preventing us from removing the
>> stderr -> null redirection from win32-nat.c ?
>
> Like so ?
>
> -- 
> Cheers,
> Pedro Alves
>

>2007-11-08  Pedro Alves  <pedro_alves@portugalmail.pt>
>
>	* win32-nat.c (safe_symbol_file_add_args,
>	safe_symbol_file_add_stub, safe_symbol_file_add_cleanup)
>	(safe_symbol_file_add): Remove.
>	(dll_symbol_command): Call symbol_file_add directly.
>
>---
> gdb/win32-nat.c |   70 --------------------------------------------------------
> 1 file changed, 1 insertion(+), 69 deletions(-)
>
>Index: src/gdb/win32-nat.c
>===================================================================
>--- src.orig/gdb/win32-nat.c	2007-11-08 23:12:36.000000000 +0000
>+++ src/gdb/win32-nat.c	2007-11-08 23:12:40.000000000 +0000
>@@ -527,19 +527,6 @@ failed:
>   return 0;
> }
> 
>-/* Encapsulate the information required in a call to
>-   symbol_file_add_args */
>-struct safe_symbol_file_add_args
>-{
>-  char *name;
>-  int from_tty;
>-  struct section_addr_info *addrs;
>-  int mainline;
>-  int flags;
>-  struct ui_file *err, *out;
>-  struct objfile *ret;
>-};
>-
> /* Maintain a linked list of "so" information. */
> struct lm_info
> {
>@@ -548,61 +535,6 @@ struct lm_info
> 
> static struct so_list solib_start, *solib_end;
> 
>-/* Call symbol_file_add with stderr redirected.  We don't care if there
>-   are errors. */
>-static int
>-safe_symbol_file_add_stub (void *argv)
>-{
>-#define p ((struct safe_symbol_file_add_args *) argv)
>-  struct so_list *so = &solib_start;
>-
>-  p->ret = symbol_file_add (p->name, p->from_tty, p->addrs, p->mainline, p->flags);
>-  return !!p->ret;
>-#undef p
>-}
>-
>-/* Restore gdb's stderr after calling symbol_file_add */
>-static void
>-safe_symbol_file_add_cleanup (void *p)
>-{
>-#define sp ((struct safe_symbol_file_add_args *)p)
>-  gdb_flush (gdb_stderr);
>-  gdb_flush (gdb_stdout);
>-  ui_file_delete (gdb_stderr);
>-  ui_file_delete (gdb_stdout);
>-  gdb_stderr = sp->err;
>-  gdb_stdout = sp->out;
>-#undef sp
>-}
>-
>-/* symbol_file_add wrapper that prevents errors from being displayed. */
>-static struct objfile *
>-safe_symbol_file_add (char *name, int from_tty,
>-		      struct section_addr_info *addrs,
>-		      int mainline, int flags)
>-{
>-  struct safe_symbol_file_add_args p;
>-  struct cleanup *cleanup;
>-
>-  cleanup = make_cleanup (safe_symbol_file_add_cleanup, &p);
>-
>-  p.err = gdb_stderr;
>-  p.out = gdb_stdout;
>-  gdb_flush (gdb_stderr);
>-  gdb_flush (gdb_stdout);
>-  gdb_stderr = ui_file_new ();
>-  gdb_stdout = ui_file_new ();
>-  p.name = name;
>-  p.from_tty = from_tty;
>-  p.addrs = addrs;
>-  p.mainline = mainline;
>-  p.flags = flags;
>-  catch_errors (safe_symbol_file_add_stub, &p, "", RETURN_MASK_ERROR);
>-
>-  do_cleanups (cleanup);
>-  return p.ret;
>-}
>-
> static struct so_list *
> win32_make_so (const char *name, DWORD load_addr)
> {
>@@ -806,7 +738,7 @@ dll_symbol_command (char *args, int from
>       args = newargs;
>     }
> 
>-  safe_symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
>+  symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
> }
> 
> /* Handle DEBUG_STRING output from child process.

That would do it but removing that code would mean lots of console
chatter unless you're debugging with the most recent, unreleased version
of the DLL.  I think we need to keep that code in gdb until the next version
of cygwin is released - and that is not even on the horizon yet.

cgf

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Pedro Alves]

Christopher Faylor wrote:
>
> On Thu, Nov 08, 2007 at 11:48:41PM +0000, Pedro Alves wrote:
> > Pedro Alves wrote:
> >> Is there anything else preventing us from removing the
> >> stderr -> null redirection from win32-nat.c ?
> >
> > Like so ?
> >
> >2007-11-08  Pedro Alves  <pedro_alves@portugalmail.pt>
> >
> >       * win32-nat.c (safe_symbol_file_add_args,
> >       safe_symbol_file_add_stub, safe_symbol_file_add_cleanup)
> >       (safe_symbol_file_add): Remove.
> >       (dll_symbol_command): Call symbol_file_add directly.
> >
>
> That would do it but removing that code would mean lots of console
> chatter unless you're debugging with the most recent, unreleased version
> of the DLL.  I think we need to keep that code in gdb until the next version
> of cygwin is released - and that is not even on the horizon yet.
>


On the current Cygwin release, having cygwin1.dbg in
/usr/bin/cygwin1.dbg when the debug info is first loaded (normally, when
the inferior is ran), is already chatty on gdb head and unfortunatelly also
on 6.7.x (except for the new cygwin snapshots, of course)  The redirection is
only done on the "dll-symbols" command.  The warnings only happen on
cygwin1.dll.  Every other dll should not have that problem, unless their
debug file format is also non conformant.  I don't think that adding
cygwin1.dll manually is a common use case.  If you don't want the
warnings on 6.7, we'll have to apply the cygwin1.dbg generation patch
on the 1.5 branch (, or wherever that is.  A pretty safe patch, in my opinion).

Unless we're talking about a different set of warnings, in which
case, let's get those fixed.

Cheers,
Pedro Alves

Re: syms_from_objfile() warnings and win32-nat.c IO redirection (Was: suppress annoying warnings about cygwin1.dbg)

[Daniel Jacobowitz]

On Fri, Nov 09, 2007 at 08:34:08AM -0500, Christopher Faylor wrote:
> >@@ -806,7 +738,7 @@ dll_symbol_command (char *args, int from
> >       args = newargs;
> >     }
> > 
> >-  safe_symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
> >+  symbol_file_add (args, from_tty, NULL, 0, OBJF_SHARED | OBJF_USERLOADED);
> > }
> > 
> > /* Handle DEBUG_STRING output from child process.
> 
> That would do it but removing that code would mean lots of console
> chatter unless you're debugging with the most recent, unreleased version
> of the DLL.  I think we need to keep that code in gdb until the next version
> of cygwin is released - and that is not even on the horizon yet.

Would it?  I don't think dll_symbol_command is automatically invoked
(in fact I've never quite understood why Cygwin has extra DLL-related
commands).

-- 
Daniel Jacobowitz
CodeSourcery