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. 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.
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.
John.
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.
Always. This is why following the ABI is so important if you want compatibility.
However, the ABI doesn't mention GC (that I've seen), so you have to
read between the lines...
cheers,
--renato