[LLVMdev] LLVM Exception Handling

[Renato Golin]

On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> wrote:
> I believe the perceived problem with using eh.exception is that
> is disassociates the source of the value with the invoke instruction that
> generated it. As far as reusing the landing pad, that is still possible, it
> would just require a phi node in the landing pad to bring all the different
> exception values together into one that could be processed by the exception
> handling code.

Let me see if I got it right...

Invokes have a specific landing pad, so you can define precisely all
predecessors of a landing pad. But the call to the @eh.exception can
be made anywhere. You shouldn't, but you can. Doing it via
predecessors or named values + PHI nodes yields exactly the same
semantics, but the second links the value to the exception and forces
the implementation to use the PHI nodes at the beginning of the
landing pad (since anywhere else would be an error).

In that case, you're forcing the user to implement the exception
handling correctly without using any new EH specific constructs. Makes
sense...

But, that is as far as it goes. The examples on getting the type and
relying on that won't work at all on dwarf debugging. As long as the
only difference is the named value + PHI nodes, I guess it would work.
I would recommend you to test also on Linux and Mac, especially with
GCC, to make sure it didn't hurt the current implementation.

As a secondary issue, I would prefer to have it typed, though. ;) I
know you're creating the value, but it makes it more difficult when
building the PHI node, if you get it wrong with another value of
different type.

-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm