This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]