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