This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: DWARF-2 EH for MinGW gcj?
- From: Danny Smith <dannysmith at clear dot net dot nz>
- To: 'GCJ' <java at gcc dot gnu dot org>
- Date: Mon, 27 Nov 2006 10:43:13 +1300
- Subject: 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