[llvm-commits] [llvm-gcc-4.2] r80850 - in /llvm-gcc-4.2/tags/Apple/llvmgcc42-2306/gcc: except.c llvm-convert.cpp

[Jim Grosbach]

On Sep 4, 2009, at 2:14 AM, Duncan Sands wrote:

> Hi Eric,
>
>> Found one myself in the project I'm trying to get working. Assert in
>> debug mode with the catch blocks lost/added weren't equal. The  
>> generated
>> llvm looks fine in practice but the invoke goes to an empty block  
>> that
>> forwards to the unwind block.
>
> you get this failure if the selectors are not in the landing pad, and
> not in the successor of the landing pad.  Then codegen doesn't know
> which invokes to associate them with.  To fix this, codegen needs to
> start from each landing pad and look for all selector calls that use
> its exception value (= result of eh.exception call), so it can  
> associate
> its catches with the invoke.  However because dwarf catches are  
> ordered,
> it is not enough to find the selector calls, you also have to order  
> them
> correctly, which in theory is hard because there might be all kinds of
> control flow logic between the landing pad and the selector calls,
> making it tricky to know which one comes first.  In practice however  
> the
> output of llvm-gcc is very regular, and probably most real cases can  
> be
> handled fairly easily.
>
> For the moment, I think you should just turn off inlining through
> invoke calls.
>
> In the long term, I think lists of globals to catch should be attached
> directly to the invoke using some kind of metadata, rather than using
> eh.selector calls.  Then everything can be handled trivially (see  
> later
> email).

Absolutely agreed. Eric and I were discussing this exact thing last  
night. It would make things much better overall if we can move away  
from the eh.selector tricks.

-Jim