This is the mail archive of the java@gcc.gnu.org mailing list for the Java 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: DWARF-2 EH for MinGW gcj?


DWARF-2 EH for MinGW gcj?
From: Mohan Embar <gnustuff at thisiscool dot com> 
To: "Ranjit Mathew" <rmathew at gmail dot com> 
Cc: java at gcc dot gnu dot org, Marco Trudel <mtrudel at gmx dot ch> 
Date: Sun, 26 Nov 2006 13:45:35 -0600 
Subject: DWARF-2 EH for MinGW gcj? 
Reply-to: gnustuff at thisiscool dot com 

------------------------------------------------------------------------
--------

.>  Hi Ranjit,

Jello Mohan I'm not Ranjit, but I'll  chip in
>
. >I know this isn't your topic of preference, but
. >can you give me quick brain dump of what you know
. >about or some pointers to issues of DWARF-2 EH for
. >MinGW gcj?
. >
. >In particular:
. >
. >- To turn DWARF2 EH back on for MinGW builds, is
. >it simply a matter of --enable-sjlj-exceptions from
. >the configure switches? Do I need --with-dwarf2? Or
. >is there more?
. >

More

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.

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 haven't gotten around to testing libgcj.dll mainly because my machine
lacks grunt.  Recent patches to
ld make sorting of section by name less time-consuming, so building the
dll is not so painfull.  


. >- Is the only issue you know about the foreign stack
. >frame issue? Or are there other caveats you know about?

AFAIK, this is the only significant issue. 

. >
. >- Any ideas or hunches on how to solve this problem?
. >Anyone else? Unless I'm missing something, it would seem
. >to me that the only way of having any hope of worming
. >our way back through foreign stack frames is to save
. >some state information before each call as we do with
. >SJLJ exceptions (if I understand this mechanism correctly,
. >which I don't claim to), which would defeat any performance
. >gains we'd hope to achieve by doing away with SJLJ exceptions....
. >

An attribute  __attibute__/pragma ((frame_wormhole_clue)) added to
foreign libcall
declarations to put state information into callee of such functions?


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



Danny

. >-- Mohan


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