[LLVMdev] LLVMdev Digest, Vol 85, Issue 50

[Peter Lawrence]

On Jul 27, 2011, at 11:10 AM, John McCall wrote:

>
>> 4)  IIUC, llvm has inherited a bug from gcc where the debugger  
>> cannot let the user know an exception is
>> going to be uncaught until after the stack has been unwound --  
>> contrary to the design intentions of the
>> unwind library that most exception implementations are based on  
>> (with a two phase unwind algorithm) --
>> which creates a problem for the debugger user.
>
> I don't see this as a compiler bug.  I can't imagine any  
> personality function
> design which would let debuggers interrupt or control unwinding  
> without
> hooking libUnwind, short of requiring every single call to have an
> associated landing pad which the personality always lands at, even if
> there's nothing to do there.  That will never, ever be acceptable.


John,
           I'm not able to figure out what you're really trying to  
say here.  I am suggesting that
there be a unique function that libUnwind calls in the event it  
detects that an exception
is going to go uncaught all the way out past main, and that the user  
be able to set a
break-point on that function (it could be the existing function  
"terminate", or a new one
created just for this one purpose),  so that the stack can be  
examined before it gets
unwound.

I'm not sure what you mean by "hooking", "interrupting", or  
"controlling".   I am just
suggesting to be allowed to set a break-point on some unique function.


I finally dug deeper into the issue and figured out this is actually  
a problem with DWARF
encoding, or the way that type info is encoded by GCC into DWARF and  
decoded by
__gcc_personality from DWARF.   (there is a comment somewhere in the  
LLVM documentation
that IIRC seems to imply the problem is with the Types parameters to  
llvm.eh.select, but
that is incorrect, the problem is deeper than that, it is with the  
underlying DWARF tables).

In short the problem is that there is an ambiguity between a cleanup  
handler having
an Action Table entry that looks like
	.byte	1		;; Type = 1 (ie #1 entry in Types Table)
	.byte	0		;; Next = 0 (ie none, ie this is the list terminator for  
this try-statement)
together with a corresponding Types Table entry #1 that looks like
	.long	0		;; RTTI pointer == NULL

and a user explicit try-catchall statement which also contains the  
exact same DWARF
encoding.

Instead a user explicit catch-all should have an explicit entry in  
the Types Table (perhaps
"void" could be the "user explicit match anything" marker) rather  
than containing the NULL value.

Right now "cleanups" look to __gcc_personality exactly like "user  
explicit catch-all", so there
is no way for __gcc_personality to tell that something will not be  
caught (if an exception will
only go through cleanups all the way out past main, it "looks" to  
__gcc_personality that it is
actually being caught by "catch-all"s, so __gcc_personality currently  
cannot figure this out
until after the stack is entirely unwound and the user is then SOL).



Peter Lawrence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/ed81de44/attachment.html>