[patch] support -gdwarf-2 when creating cygwin1.dbg

[Charles Wilson]

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