John,
I'm still not sure what you're talking about, I have
included the assembly
output from two compilations, one with a user explicit catch-all, one
with only an
implicit cleanup, the DWARF Action Table and Types Table are
absolutely identical,
as are the indexes used to reference the Action Table from the region
maps.
-Peter Lawrence.
------------------------------------------------------------------------
---------------------------------------
extern void foo();
extern void print(const char *) __attribute__((nothrow));
void bar ()
{
try {
foo();
} catch (...) {
print("caught (...)\n");
}
}
.section __TEXT,__gcc_except_tab
...
;; CallSite Table
.long Ltmp0-Leh_func_begin0
.long Ltmp1-Ltmp0 <--- this region
covers the call to foo
.long Ltmp2-Leh_func_begin0
.byte 1 <--- this is it's
Action Table index
...
;; Action Table
.byte 1
.byte 0
;; Types Table
.long 0
------------------------------------------------------------------------
---------------------------------------
extern void foo();
extern void print(const char *) __attribute__((nothrow));
class Bob {
public:
Bob() __attribute__((nothrow));
~Bob() __attribute__((nothrow));
};
void bar ()
{
Bob A, B, C;
foo();
//~Bob C, B, Z;
}
.section __TEXT,__gcc_except_tab
...
;; CallSite Table
.long Ltmp0-Leh_func_begin0
.long Ltmp1-Ltmp0 <--- this region covers the call to foo
.long Ltmp2-Leh_func_begin0
.byte 1 <--- here is its Action Table index
...
;; Action Table
.byte 1
.byte 0
;; Types Table
.long 0
------------------------------------------------------------------------
---------------------------------------
On Jul 28, 2011, at 1:00 PM, John McCall wrote:
> On Jul 28, 2011, at 8:41 AM, Peter Lawrence wrote:
>> 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
>
> This is not a cleanup. In the LSDAs for GCC's family of
> personalities, cleanups
> by definition have a zero index into the types table. I think I
> see your confusion,
> though.
>
> LLVM-GCC and Clang used to share a bug where cleanups would sometimes
> be emitted as catch-alls as a workaround to a flaw in the inliner.
> I fixed this
> flaw (or to be specific, I worked around it to the best of my
> ability given the
> constraints of the broken eh.exception/eh.selector representation)
> sometime
> in June, but part of the fix requires the front-end to emit
> different code, and I've
> only updated Clang to do so because I can't touch dragonegg and
> LLVM-GCC
> is dead.
>
> AFAIK, GCC never had this bug.
>
> John.
On Jul 28, 2011, at 2:22 PM, Peter Lawrence wrote:> John, > I'm still not sure what you're talking about, I have included the assembly > output from two compilations, one with a user explicit catch-all, one with only an > implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, > as are the indexes used to reference the Action Table from the region maps.What compiler are you talking about, and on what platform? The results I'm seeing clearly have both gcc and clang on Darwin generating different LSDAs for your cleanup examples and your catch-all examples. Here is the output I see from gcc-4.2 for your cleanup example: .text .globl __Z3barv __Z3barv: LFB2: pushq %rbp LCFI0: movq %rsp, %rbp LCFI1: pushq %rbx LCFI2: subq $40, %rsp LCFI3: leaq -17(%rbp), %rdi call __ZN3BobC1Ev leaq -18(%rbp), %rdi call __ZN3BobC1Ev leaq -19(%rbp), %rdi call __ZN3BobC1Ev LEHB0: call __Z3foov LEHE0: <snip> .section __TEXT,__gcc_except_tab GCC_except_table0: LLSDA2: .byte 0xff .byte 0xff .byte 0x3 .byte 0x1a .set L$set$0,LEHB0-LFB2 # from .long L$set$0 .set L$set$1,LEHE0-LEHB0 .long L$set$1 .set L$set$2,L6-LFB2 .long L$set$2 .byte 0x0 i.e. the range of instructions covering the call to foo() has an action table index of 0, meaning a cleanup. Here is the output of ToT clang on this code: __Z3barv: ## @_Z3barv Ltmp5: .cfi_startproc .cfi_personality 155, ___gxx_personality_v0 Leh_func_begin0: .cfi_lsda 16, Lexception0 ## BB#0: ## %entry pushq %rbp Ltmp6: .cfi_def_cfa_offset 16 Ltmp7: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp8: .cfi_def_cfa_register %rbp subq $80, %rsp leaq -8(%rbp), %rdi callq __ZN3BobC1Ev leaq -16(%rbp), %rdi callq __ZN3BobC1Ev leaq -24(%rbp), %rdi callq __ZN3BobC1Ev Ltmp0: callq __Z3foov Ltmp1: <snip> .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: Lexception0: .byte 255 ## @LPStart Encoding = omit .byte 155 ## @TType Encoding = indirect pcrel sdata4 .byte 156 ## @TType base offset .space 1 .byte 3 ## Call site Encoding = udata4 .byte 26 ## Call site table length ## >> Call Site 1 << ## Call between Ltmp0 and Ltmp1 ## jumps to Ltmp2 ## On action: cleanup Lset0 = Ltmp0-Leh_func_begin0 .long Lset0 Lset1 = Ltmp1-Ltmp0 .long Lset1 Lset2 = Ltmp2-Leh_func_begin0 .long Lset2 .byte 0 Same thing. For contrast, here is the result from gcc-4.2 on your catch-all code: .globl __Z3barv __Z3barv: LFB2: pushq %rbp LCFI0: movq %rsp, %rbp LCFI1: LEHB0: call __Z3foov LEHE0: <snip> .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: LLSDA2: .byte 0xff .byte 0x9b .byte 0x25 .byte 0x3 .byte 0x1a .set L$set$0,LEHB0-LFB2 .long L$set$0 .set L$set$1,LEHE0-LEHB0 .long L$set$1 .set L$set$2,L6-LFB2 .long L$set$2 .byte 0x1 # <-- a non-zero index into the action table .set L$set$3,LEHB1-LFB2 .long L$set$3 .set L$set$4,LEHE1-LEHB1 .long L$set$4 .long 0x0 .byte 0x0 .byte 0x1 # <-- first entry (index=1) in the action table .byte 0x0 .align 2 .long 0 # <-- the first entry (index=1) in the types table, a catch-all And from ToT Clang: __Z3barv: ## @_Z3barv Ltmp5: .cfi_startproc .cfi_personality 155, ___gxx_personality_v0 Leh_func_begin0: .cfi_lsda 16, Lexception0 ## BB#0: ## %entry pushq %rbp Ltmp6: .cfi_def_cfa_offset 16 Ltmp7: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp8: .cfi_def_cfa_register %rbp subq $32, %rsp Ltmp0: callq __Z3foov Ltmp1: .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: Lexception0: .byte 255 ## @LPStart Encoding = omit .byte 155 ## @TType Encoding = indirect pcrel sdata4 .byte 162 ## @TType base offset .space 2,128 .space 1 .byte 3 ## Call site Encoding = udata4 .byte 26 ## Call site table length ## >> Call Site 1 << ## Call between Ltmp0 and Ltmp1 ## jumps to Ltmp2 ## On action: 1 Lset0 = Ltmp0-Leh_func_begin0 .long Lset0 Lset1 = Ltmp1-Ltmp0 .long Lset1 Lset2 = Ltmp2-Leh_func_begin0 .long Lset2 .byte 1 ## >> Call Site 2 << ## Call between Ltmp1 and Leh_func_end0 ## has no landing pad Lset3 = Ltmp1-Leh_func_begin0 .long Lset3 Lset4 = Leh_func_end0-Ltmp1 .long Lset4 .long 0 .byte 0 ## >> Action Record 1 << ## Catch TypeInfo 1 ## No further actions .byte 1 .byte 0 ## >> Catch TypeInfos << .long 0 ## TypeInfo 1 John.
John,
I have been using the first official release llvm-2.9
tarball and a clang from very shortly after that,
built for my PowerPC-Apple-Darwin,
I am a bit surprised that this would have changed since then, but
pleasantly surprised nevertheless.
Peter Lawrence.
On Jul 28, 2011, at 2:49 PM, John McCall wrote:
> On Jul 28, 2011, at 2:22 PM, Peter Lawrence wrote:
>> John,
>> I'm still not sure what you're talking about, I have
>> included the assembly
>> output from two compilations, one with a user explicit catch-all,
>> one with only an
>> implicit cleanup, the DWARF Action Table and Types Table are
>> absolutely identical,
>> as are the indexes used to reference the Action Table from the
>> region maps.
>
> What compiler are you talking about, and on what platform?
>
> The results I'm seeing clearly have both gcc and clang on Darwin
> generating
> different LSDAs for your cleanup examples and your catch-all examples.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110728/86139808/attachment.html>