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


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


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