On Sun, Mar 6, 2011 at 7:37 PM, John McCall <rjmccall at apple.com> wrote:
> On Mar 6, 2011, at 11:01 AM, Talin wrote:
> > Here's an interesting problem - is it legal to copy the
_Unwind_Exception
> struct to a different address in memory before calling _Unwind_Resume?
> >
> > I'm thinking of the scenario in which a garbage collection run is
> triggered in the middle of a "finally" block. If it's a
copying collector,
> it might relocate the exception object, which has the _Unwind_Exception
> structure embedded in the middle of it. I don't see why this
wouldn't work,
> but I thought I'd ask around to be sure.
>
> This is really a question about the Itanium EH ABI, so I'm not sure why
> you're asking it here.
Only because I couldn't think of where else to ask :)
> That said, the ABI does not permit you to move exception objects in
> general, because even if you're working in a language where every
object can
> be trivially moved, any given exception might be a "foreign"
exception from
> a language (like C++) which does not provide this guarantee.
>
> Foreign exceptions would be in a different heap, so the garbage collector
wouldn't attempt to move them or even be aware of their existence. I can see
that there might be a problem if C++ code caught one of *my* exceptions
which subsequently moved, although the exception wouldn't be moved until
sometime after control passed back to my code, since the garbage collector
only moves objects during safe points, and the foreign code wouldn't have
safe point calls. This just means that people who call methods written in my
language from other languages will have to be careful about exception
handling.
> Also, the ABI basically requires the EH implementation to internally
> maintain references to active exception objects under certain
circumstances;
> you'll need to treat those as GC roots, which means hard-coding
knowledge
> of the implementation into your collector / runtime.
>
> That's not a problem, my code already does that.
> John.
--
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110306/bfbc5fbc/attachment.html>