Displaying 7 results from an estimated 7 matches for "__gcc_except_tab".
2011 Jul 28
2
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...----
---------------------------------------
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
......
2010 Feb 05
3
[LLVMdev] Exception Table Padding Change
Hi Duncan et al,
Our linker guy brought up a problem with how we pad out our exception tables. Right now we pad them out like this:
.section __DATA,__gcc_except_tab
.align 2
GCC_except_table13:
.byte 0x0 #< --- hun?
.byte 0x0 #< --- hun?
Lexception13:
.byte 0xFF
.byte 0x0
.byte 0xB2, 0x1
>
Here are his comments:
The problem is that the linker parses FDE which gives it all the LSDA starts. The __eh_frame and __gcc_except_tab sections...
2011 Jul 28
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...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 o...
2011 Jul 28
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
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
2011 Jul 28
2
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
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
2010 Apr 22
0
[LLVMdev] Books/docs on exception handling
...s an amalgam of several different documents and code tables, which all conspire to give us exception handling. :-) The documents you should read are:
* Exception Handling Tables (http://www.codesourcery.com/public/cxx-abi/exceptions.pdf)
This explains in detail what the table in the "__TEXT,__gcc_except_tab" section is all about.
* DWARF Debugging Information Format: Version 3 (or 4)
This explains the "CIE" and "FDE" tables and what their encodings means.
* http://www.codesourcery.com/public/cxx-abi/abi-eh.html
As Eugene pointed out, this explains what the personality fu...
2010 Apr 21
3
[LLVMdev] Books/docs on exception handling
Hi,
I'm trying to learn all that I can about exception handling from the
compiler's point of view. Although much has been written about
compiler theory in general -- parsing, code generation, you name it --
I can find almost nothing on the specific problem of exception
handling support. In fact, the most informative document I've been
able to find so far is "Bill's