search for: __ztii

...", c); } } The cleanup part for the "foo" call has this: L24: # basic block 4 L3: movl %edx, %ebx movq %rax, %r13 movl $4, %edi call ___cxa_allocate_exception movq %rax, %rdi movl $0, (%rax) movq __ZTIi at GOTPCREL(%rip), %rsi xorl %edx, %edx LEHB2: call ___cxa_throw LEHE2: edx and rax hold the EH selector value and EH object pointer respectively. They get restored before continuing on to the catch in bar (if they get there, which I don't think they will in this case)....

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,

...$set$6 # region 2 start .set L$set$7,LEHE2-LEHB2 .long L$set$7 # length .set L$set$8,L24-LFB4 .long L$set$8 # landing pad .byte 0x7 # uleb128 0x7; action . . . .byte 0x1 # Action record table .byte 0x0 .byte 0x2 .byte 0x7d .byte 0x3 .byte 0x7d .byte 0x0 .byte 0x7d .align 2 .long __ZTIi+4 at GOTPCREL .long __ZTIPKc+4 at GOTPCREL .long 0 If the call to __Z3foov throws, we need to set up the tables to that it knows that it needs to call the __ZN1BD1Ev and __ZN1AD1Ev cleanups. This information requires looking at the invoke instruction – i.e., "where should I land?". It...

Hi Bill, > This is similar to my first proposal. yup, I still consider your first proposal to have been basically sound. But it also suffers from a major problem, > which stopped that proposal dead in its tracks. Namely, you have information in > one place which needs to be shared in two different, but possibly disjoint, > places: the type, filters, and personality information. In