[patch] support -gdwarf-2 when creating cygwin1.dbg
The attached patch allows for dllfixdbg to copy DWARF-2 debug sections
into the .dbg file. There was also an (accidently?) duplicated section
in the cygwin.sc linker script that I removed while I was there.
The advantages of being able to build newlib/winsup with -gdwarf-2 in
C/CXXFLAGS are a ~38% smaller .dbg file, but more importantly a much
more pleasant debugger experience. gdb is not nearly as confused about
the sigfe/sigbe signal wrappers, and can unwind the stack cleanly all
the way up to mainCRTStartup() even when stepping through deep internal
cygwin1.dll guts.
Here's an example from a simple hello world exe. With -gdwarf-2:
(gdb) bt
#0 fstat64 (fd=1, buf=0x22afd0)
at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1102
#1 0x610b4928 in _fstat64_r (ptr=0x50001, fd=327681, buf=0x50001)
at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1115
#2 0x61107174 in __smakebuf_r (ptr=0x22d008, fp=0x64f8)
at /usr/src/sourceware/newlib/libc/stdio/makebuf.c:53
#3 0x6110667b in __swsetup_r (ptr=0x50001, fp=0x64f8)
at /usr/src/sourceware/newlib/libc/stdio/wsetup.c:67
#4 0x610f21a6 in _vfprintf_r (data=0x22d008, fp=0x64f8,
fmt0=0x402000 Hello world\n, ap=0x22cca4 /)
at /usr/src/sourceware/newlib/libc/stdio/vfprintf.c:547
#5 0x610ff208 in printf (
fmt=0x22eea8e0 Address 0x22eea8e0 out of bounds)
at /usr/src/sourceware/newlib/libc/stdio/printf.c:51
#6 0x610a5498 in _sigfe ()
at /usr/src/sourceware/winsup/cygwin/cygserver.h:82
#7 0x0009 in ?? ()
#8 0x61005efa in dll_crt0_1 ()
at /usr/src/sourceware/winsup/cygwin/dcrt0.cc:943
#9 0x61004216 in _cygtls::call2 (this=0x22ce64,
func=0x610052a0 dll_crt0_1(void*), arg=0x0, buf=0x22cdd0)
at /usr/src/sourceware/winsup/cygwin/cygtls.cc:74
#10 0x61004290 in _cygtls::call (func=0x610a5498 _sigbe, arg=0x0)
at /usr/src/sourceware/winsup/cygwin/cygtls.cc:67
#11 0x61005171 in _dll_crt0 ()
at /usr/src/sourceware/winsup/cygwin/dcrt0.cc:956
#12 0x004010e3 in cygwin_crt0 (f=0x401040 main)
at /usr/src/sourceware/winsup/cygwin/lib/cygwin_crt0.c:32
#13 0x0040103d in mainCRTStartup ()
at /usr/src/sourceware/winsup/cygwin/crt0.c:51
Exact same breakpoint, -g (stabs):
(gdb) bt
#0 fstat64 (fd=1628141592, buf=0x1)
at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1102
#1 0x611b5708 in _libntdll_a_iname () from /bin/cygwin1.dll
#2 0x in ?? ()
Brian2007-04-18 Brian Dessent [EMAIL PROTECTED]
* cygwin.sc: Remove duplicated .debug_macinfo section.
* dllfixdbg: Also copy DWARF-2 sections into .dbg file.
Index: cygwin.sc
===
RCS file: /cvs/src/src/winsup/cygwin/cygwin.sc,v
retrieving revision 1.21
diff -u -p -r1.21 cygwin.sc
--- cygwin.sc 12 Jan 2007 19:40:20 - 1.21
+++ cygwin.sc 18 Apr 2007 12:16:52 -
@@ -138,6 +138,5 @@ SECTIONS
.debug_str ALIGN(__section_alignment__) (NOLOAD) : { *(.debug_str) }
.debug_loc ALIGN(__section_alignment__) (NOLOAD) : { *(.debug_loc) }
.debug_macinfo ALIGN(__section_alignment__) (NOLOAD) : { *(.debug_macinfo) }
- .debug_macinfo ALIGN(__section_alignment__) (NOLOAD) : { *(.debug_macinfo) }
.debug_ranges ALIGN(__section_alignment__) (NOLOAD) : { *(.debug_ranges) }
}
Index: dllfixdbg
===
RCS file: /cvs/src/src/winsup/cygwin/dllfixdbg,v
retrieving revision 1.4
diff -u -p -r1.4 dllfixdbg
--- dllfixdbg 14 Jul 2006 19:33:55 - 1.4
+++ dllfixdbg 18 Apr 2007 12:16:52 -
@@ -16,7 +16,10 @@ my $objdump = shift;
my @objcopy = ((shift));
my $dll = shift;
my $dbg = shift;
-xit 0, @objcopy, '-j', '.stab', '-j', '.stabstr', $dll, $dbg;
+xit 0, @objcopy, '-j', '.stab', '-j', '.stabstr', '-j', '.debug_aranges',
+ '-j', '.debug_pubnames', '-j', '.debug_info', '-j', '.debug_abbrev',
+ '-j', '.debug_line', '-j', '.debug_frame', '-j', '.debug_str', '-j',
+ '.debug_loc', '-j', '.debug_macinfo', '-j', '.debug_ranges', $dll, $dbg;
xit 0, @objcopy, '-g', '--add-gnu-debuglink=' . $dbg, $dll;
open(OBJDUMP, '-|', $objdump --headers $dll);
my %section;
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
On Wed, Apr 18, 2007 at 05:44:25AM -0700, Brian Dessent wrote: The attached patch allows for dllfixdbg to copy DWARF-2 debug sections into the .dbg file. There was also an (accidently?) duplicated section in the cygwin.sc linker script that I removed while I was there. The advantages of being able to build newlib/winsup with -gdwarf-2 in C/CXXFLAGS are a ~38% smaller .dbg file, but more importantly a much more pleasant debugger experience. gdb is not nearly as confused about the sigfe/sigbe signal wrappers, and can unwind the stack cleanly all the way up to mainCRTStartup() even when stepping through deep internal cygwin1.dll guts. Here's an example from a simple hello world exe. With -gdwarf-2: (gdb) bt #0 fstat64 (fd=1, buf=0x22afd0) at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1102 #1 0x610b4928 in _fstat64_r (ptr=0x50001, fd=327681, buf=0x50001) at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1115 #2 0x61107174 in __smakebuf_r (ptr=0x22d008, fp=0x64f8) at /usr/src/sourceware/newlib/libc/stdio/makebuf.c:53 #3 0x6110667b in __swsetup_r (ptr=0x50001, fp=0x64f8) at /usr/src/sourceware/newlib/libc/stdio/wsetup.c:67 #4 0x610f21a6 in _vfprintf_r (data=0x22d008, fp=0x64f8, fmt0=0x402000 Hello world\n, ap=0x22cca4 /) at /usr/src/sourceware/newlib/libc/stdio/vfprintf.c:547 #5 0x610ff208 in printf ( fmt=0x22eea8e0 Address 0x22eea8e0 out of bounds) at /usr/src/sourceware/newlib/libc/stdio/printf.c:51 #6 0x610a5498 in _sigfe () at /usr/src/sourceware/winsup/cygwin/cygserver.h:82 #7 0x0009 in ?? () #8 0x61005efa in dll_crt0_1 () at /usr/src/sourceware/winsup/cygwin/dcrt0.cc:943 #9 0x61004216 in _cygtls::call2 (this=0x22ce64, func=0x610052a0 dll_crt0_1(void*), arg=0x0, buf=0x22cdd0) at /usr/src/sourceware/winsup/cygwin/cygtls.cc:74 #10 0x61004290 in _cygtls::call (func=0x610a5498 _sigbe, arg=0x0) at /usr/src/sourceware/winsup/cygwin/cygtls.cc:67 #11 0x61005171 in _dll_crt0 () at /usr/src/sourceware/winsup/cygwin/dcrt0.cc:956 #12 0x004010e3 in cygwin_crt0 (f=0x401040 main) at /usr/src/sourceware/winsup/cygwin/lib/cygwin_crt0.c:32 #13 0x0040103d in mainCRTStartup () at /usr/src/sourceware/winsup/cygwin/crt0.c:51 Exact same breakpoint, -g (stabs): (gdb) bt #0 fstat64 (fd=1628141592, buf=0x1) at /usr/src/sourceware/winsup/cygwin/syscalls.cc:1102 #1 0x611b5708 in _libntdll_a_iname () from /bin/cygwin1.dll #2 0x in ?? () Brian 2007-04-18 Brian Dessent [EMAIL PROTECTED] * cygwin.sc: Remove duplicated .debug_macinfo section. * dllfixdbg: Also copy DWARF-2 sections into .dbg file. Thanks for doing this. Please check in. Can we switch to dwarf-2 by default in the cygwin makefile(s)? cgf
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
On Apr 18 08:58, Christopher Faylor wrote: On Wed, Apr 18, 2007 at 05:44:25AM -0700, Brian Dessent wrote: The attached patch allows for dllfixdbg to copy DWARF-2 debug sections into the .dbg file. There was also an (accidently?) duplicated section in the cygwin.sc linker script that I removed while I was there. [...] Thanks for doing this. Please check in. Can we switch to dwarf-2 by default in the cygwin makefile(s)? As long as we use a 3.x or 4.0.x gcc it should be ok. Later gcc's explicitely switch off the generation of a DW_CFA_offset column in the .debug_frame CIE header information, which breaks backtracing in GDB. There's an explicit #define DWARF2_UNWIND_INFO 0 in gcc/config/i386/cygming.h right now. The accompanying comment is /* DWARF2 Unwinding doesn't work with exception handling yet. To make it work, we need to build a libgcc_s.dll, and dcrt0.o should be changed to call __register_frame_info/__deregister_frame_info. */ I didn't see any problem with using dwarf2 in Cygwin so far and actually it lets GDB behave much better than with stabs. I'm not fluent enough with this low-level stuff so I don't quite understand what this __register_frame_info/__deregister_frame_info stuff is about. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
Christopher Faylor wrote: Thanks for doing this. Please check in. Can we switch to dwarf-2 by default in the cygwin makefile(s)? I thought about that, but the problem is anything you do to *FLAGS in winsup/cygwin won't affect flags used in the other dirs like libiberty or newlib, and so unless you set CXXFLAGS and CFLAGS when you do toplevel configure, you'll end up with a mish-mash of some stabs and some DW2 in the .dbg file. Corinna Vinschen wrote: As long as we use a 3.x or 4.0.x gcc it should be ok. Later gcc's explicitely switch off the generation of a DW_CFA_offset column in the .debug_frame CIE header information, which breaks backtracing in GDB. Hmm, I think I read something about that on the gcc list. Is this just a case of gcc switching to doing TheActualRightThing and gdb not having being updated yet? There's an explicit #define DWARF2_UNWIND_INFO 0 in gcc/config/i386/cygming.h right now. The accompanying comment is Aren't we talking about two different things here? That's for unwinding during exception handling, but you can still leave that at 0 (and use --enable-sjlj-exceptions) and still get the benefit of -gdwarf-2 for gdb's consumption. Brian
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
On Wed, Apr 18, 2007 at 06:17:59AM -0700, Brian Dessent wrote: Christopher Faylor wrote: Thanks for doing this. Please check in. Can we switch to dwarf-2 by default in the cygwin makefile(s)? I thought about that, but the problem is anything you do to *FLAGS in winsup/cygwin won't affect flags used in the other dirs like libiberty or newlib, and so unless you set CXXFLAGS and CFLAGS when you do toplevel configure, you'll end up with a mish-mash of some stabs and some DW2 in the .dbg file. So, maybe a top-level configure option would be useful? At the very least we can get rid of the -gstabs specific use in configure. Corinna Vinschen wrote: As long as we use a 3.x or 4.0.x gcc it should be ok. Later gcc's explicitely switch off the generation of a DW_CFA_offset column in the .debug_frame CIE header information, which breaks backtracing in GDB. Hmm, I think I read something about that on the gcc list. Is this just a case of gcc switching to doing TheActualRightThing and gdb not having being updated yet? There's an explicit #define DWARF2_UNWIND_INFO 0 in gcc/config/i386/cygming.h right now. The accompanying comment is Aren't we talking about two different things here? That's for unwinding during exception handling, but you can still leave that at 0 (and use --enable-sjlj-exceptions) and still get the benefit of -gdwarf-2 for gdb's consumption. IIRC, this is turned on because of funkiness with exception unwinding in DLLs. cgf
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
Christopher Faylor wrote:
So, maybe a top-level configure option would be useful? At the very least
we can get rid of the -gstabs specific use in configure.
Oh, I didn't know there was anything that specifically mentions -gstabs
in there, just that if you don't set {C,CXX}FLAGS yourself autoconf uses
-g -O2. To me it seems simple enough for now just to require:
.../toplev/configure CXXFLAGS=-gdwarf-2 -O2 CFLAGS=-gdwarf-2 -O2
And then at some point in the future, release updated gcc packages where
-g equals -gdwarf-2 rather than -gstabs (but still without touching any
of the exception handling stuff.)
Aren't we talking about two different things here? That's for unwinding
during exception handling, but you can still leave that at 0 (and use
--enable-sjlj-exceptions) and still get the benefit of -gdwarf-2 for
gdb's consumption.
IIRC, this is turned on because of funkiness with exception unwinding in
DLLs.
I think there were/are two issues:
1. throw/catch unwinding across DLL boundaries currently works but
requires MinGW/Cygwin-local patches that were never championed/accepted
upstream because they were too ugly (and I think Danny said this area
has changed enough in 4.x that they don't forward port at all.) The
pain here might have been related to the fact that currently all target
libraries are static (libgcc, libstdc++, etc) which means there are 'n'
copies of the libgcc code in memory instead of just one in a DLL. So we
need shared target libs, then this becomes simpler.
2. Dwarf-2 EH unwinding through a foreign frame causes problems, one
example of which is where your code is registered with a Win32 API as a
callback and you want to throw from inside that callback. When the
unwinder goes up the stack there is one or more frames inside of
USER32.DLL or NTDLL.DLL or something and it gets lost. This is the one
that is somewhat intractible and would cause us to either foresake that
use pattern or stick with SJLJ. Or maybe somebody will have a bright
idea.
Brian
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
Corinna Vinschen wrote: I debugged Cygwin native GDB a couple of days ago with code created by gcc 4.2. It turned out that the DWARF2_UNWIND_INFO define set to 0 resulted in the DW_CFA_offset column missing. The result is that GDB is unable to get the return address on the stack when using the dwarf2 frame sniffer. Setting DWARF2_UNWIND_INFO to 1 in gcc/config/i386/cygming.h results in gcc emitting the missing DW_CFA_offset column and GDB is happy again. Older gcc's = 4.0.1 always created the DW_CFA_offset column, so GDB is always happy with the created debug info. Ah, I see. That makes sense. I'm not at all fluent with this stuff. Is that really important for Cygwin? It's not at all important to cygwin1.dll itself but it could be very relevant to Cygwin users that want to make use of C++ code that makes use of exceptions. Danny Smith said he was preparing to release a gcc 4.2.x for MinGW in the somewhat-near future, and since he knows the most about all of this we can wait and see what he decides to do about it. If it's possible to get Dwarf exceptions working in those few corner cases, then that would be great; it's much faster than SJLJ and obviously for the purposes of debug info it's way better. If it turns out that we'll be sticking with SJLJ EH then I think it would be reasonable to try to work up a patch that causes DW_CFA_offset to be set even if not using Dwarf for EH. Brian
