RE: DWARF-2 EH for MinGW gcj?

[Andrew Haley <aph at redhat dot com>]

Danny Smith writes:
 > 
 >  Mohan Embar 
 >  Monday, 27 November 2006 11:52 a.m.
 > > 
 > > Hi Danny,
 > > 
 > >
 > > >I promise to submit a Part 1 patch by end of this week. If you would
 > > >like to review first, I can send you working version.
 > > 
 > > What does Part 1 do? I wouldn't mind looking at this, although
 > > it will probably be Greek to me.
 > 
 > Basically just registers the unwind info tables at startup.
 > 
 > http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html
 >  
 > > 
 > > >Part 2  builds libgcc amd libstdc++ as dlls (c++ frontend patch for
 > > >typeinfo linkage needed for latter).
 > > >This takes care of EH across dll/exe bounds for C++with out need for
 > > >shared-ptr hackery
 > > 
 > > I'm assuming that this would mean that application developers would
 > > need to ship these DLLs with their applications. 
 > 
 > Yes.
 > 
 > Would this preclude
 > > monolithic statically-linked executables? 
 > 
 > If *not* throwing execeptions across shared library boundaries, static
 > linkage would still work fine for C/C++. 
 > 
 > > What are the GPL implications of this?

Can't see any.  Where do you suspect that there might be?

 > > >From what I understand of MSVC compiler for Vista, EH unwind is
 > > handled >using DWARF2-like tables.  Does anyone have any more
 > > info?

Aren't they still using SEH for x86?

I heard on the x86-64 they're using a table-based scheme that's like
DWARF but (of course) incompatible.

Andrew.