This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [patch] support -gdwarf-2 when creating cygwin1.dbg
Chiming in with a general comment: dwarf2 exceptions are different than
dwarf2 debug info. However, obviously both varieties of "dwarf2" can
impact gdb.
I finished a build last weekend of gcc trunk with
(1) Steve Ellcey's recently-accepted "pre switch to modern libtool" patch
(2) Steve Ellcey's "actually use modern libtool"
(3) a forward port of Danny Smith's "[PATCH] Dwarf 2 Unwind frames
for mingw32/cygwin"
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html to current trunk
(4) a minor patch to "convert" libgcc to toplevel for cygwin target
(#3 from Dec 2006 doesn't work without this, because of the
toplevel-libgcc changes from Jan 2007)
http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration
This had reasonable success [*] (after the testsuite finally finished,
60-odd hours later...) Note that Danny's changes modify the comment
block above the DWARF2_UNWIND_INFO macro setting from:
-/* 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. */
-#define DWARF2_UNWIND_INFO 0
+/* DWARF2 Unwinding is default exception handling model. Configure
+ with -enable-sjlj-exceptions to revert to old setjump/longjump
+ model. */
+#define DWARF2_UNWIND_INFO 1
There does not seem to be any requirement, with Danny's patch, for
libgcc to be built shared. However, Danny's patch only allows us to use
dwarf2 exception unwinding in place of sjlj, in gcc trunk.
gcc 4.x+ on cygming, at present, does NOT support catching exceptions
thrown across DLL boundaries for EITHER sjlj or dwarf2, regardless of
whether Danny's patch above is used. THAT piece is what requires the
3.4.x hack, which as Brian mentioned is not yet/nor will be ported to
4.x. Instead, according to Danny, proper "catch an exception thrown
across DLL bounds" in gcc-4.x is the driving factor requiring a shared
libgcc (and shared libsupc++/libstdc++) in the absence of a forward port
of the 3.4.x hack.
But not even that will solve the "catch a dwarf2 exception thrown from a
Win32 callback" problem (aka the 'foreign frame' problem). THAT issue
is a possible Summer of Code 2007 project:
http://gcc.gnu.org/wiki/WindowsGCCImprovements
I've got some stuff in development to build libgcc shared on cygwin --
libgcc is built without libtool (old OR new). We can tackle
libsupc++/libstdc++ after the second of Steve Ellcey's patches goes in.
--
Chuck
=================================================================
[*] selected parts of the test log:
=== gcc Summary ===
# of expected passes 45512
# of unexpected failures 33
# of unexpected successes 1
# of expected failures 115
# of untested testcases 35
# of unsupported tests 343
=== g++ Summary ===
# of expected passes 14719
# of unexpected failures 28
# of unexpected successes 3
# of expected failures 79
# of unsupported tests 159
=== libstdc++ Summary ===
# of expected passes 4856
# of unexpected failures 879
# of unexpected successes 2
# of expected failures 39
# of unsupported tests 466
(most of the libstdc++ failures were locale-related, and should probably
be in the unsupported category...)