search for: gcc_except_t

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it causes overflows in general case. And...

hi: maybe this should not be here! the test code: eh3.cpp int main() { try { throw 34; } catch (int) { } catch (char) { } catch (bool) { } } compile with g++ -S -dA eh3.cpp -o eh3.s the except table of the eh3.s 106 .section .gcc_except_table,"a", at progbits 107 .align 4 108 .LLSDA2: 109 .byte 0xff # @LPStart format (omit) 110 .byte 0x0 # @TType format (absolute) 111 .uleb128 .LLSDATT2-.LLSDATTD2 # @TType base offset 112 .LLSDATTD2: 113 .byte...

Hi, > maybe this should not be here! does this have anything to do with LLVM? > int main() > { > try { > throw 34; > } > catch (int) { > } > catch (char) { > } > catch (bool) { > } > } The action is 0x5, this refers to 123 .byte 0x3 124 .byte 0x7d where 0x3 means that the typeinfo

On 07/08/2011 01:25 PM, Yuri wrote: > ELF that MCJIT writes on x86_64 has relocations in it. Particularly, > R_X86_64_PC32 relocations are used for the sections .gcc_except_table > and .eh_frame related to exception processing. > I am not sure where is general documentation on relocation types, > including R_X86_64_PC32. Looks like it's nowhere to be found on the web. > But 32-bit relocation can't be used in 64-bit code since it causes > overflows...

....unwind_info : { KEEP(*(.IA_64.unwind_info* .gnu.linkonce.ia64unwi.*)) } + .IA_64.unwind : { KEEP(*(.IA_64.unwind* .gnu.linkonce.ia64unw.*)) } + .eh_frame_hdr : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) } + .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) } + .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table + .gcc_except_table.*) } + .gnu_extab : ONLY_IF_RO { *(.gnu_extab*) } + /* These sections are generated by the Sun/Oracle C++ compiler. */ + .exception_ranges : ONLY_IF_RO { *(.exception_ranges + .exception_ranges*) } + /* Adjust the address for t...

....unwind_info : { KEEP(*(.IA_64.unwind_info* .gnu.linkonce.ia64unwi.*)) } + .IA_64.unwind : { KEEP(*(.IA_64.unwind* .gnu.linkonce.ia64unw.*)) } + .eh_frame_hdr : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) } + .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) } + .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table + .gcc_except_table.*) } + .gnu_extab : ONLY_IF_RO { *(.gnu_extab*) } + /* These sections are generated by the Sun/Oracle C++ compiler. */ + .exception_ranges : ONLY_IF_RO { *(.exception_ranges + .exception_ranges*) } + /* Adjust the address for t...

...set 3, -16 > movq %rdi, %rbx > call *%rdi > movq %rbx, %rax > popq %rbx > .cfi_def_cfa_offset 8 > jmp *%rax > .cfi_endproc > .LFE1: > .globl __gxx_personality_v0 > .section .gcc_except_table,"a", at progbits > .LLSDA1: > .byte 0xff > .byte 0xff > .byte 0x1 > .uleb128 .LLSDACSE1-.LLSDACSB1 > .LLSDACSB1: > .LLSDACSE1: > .text > .size _Z5test2PFvvE, .-_Z5test2PFvvE > .section...

...istory!) for a backend that i was implementing. I have been trying to port my patches to latest llvm (svn build) lately but i have one problem as far as the Exception Handling mechanism is concerned. It seems that there are no Exception Tables generated any more such as the one below: .section .gcc_except_table,"a", at progbits .align 4 GCC_except_table0: .Lexception0: .byte 255 # @LPStart Encoding = omit .byte 3 # @TType Encoding = udata4 .uleb128 41 # @TType base offset .byte 3 #...

...there are no Exception Tables generated any more such >> as the one below: > > got some example bitcode for which you see this (or, rather, don't see this > since the problem is that you are not seeing exception tables)? > > Ciao, Duncan. > >> >> .section .gcc_except_table,"a", at progbits >> .align 4 >> GCC_except_table0: >> .Lexception0: >> .byte 255 # @LPStart Encoding = omit >> .byte 3 # @TType Encoding = udata4 >> .uleb128 41...

...anism is > concerned. It seems that there are no Exception Tables generated any more such > as the one below: got some example bitcode for which you see this (or, rather, don't see this since the problem is that you are not seeing exception tables)? Ciao, Duncan. > > .section .gcc_except_table,"a", at progbits > .align 4 > GCC_except_table0: > .Lexception0: > .byte 255 # @LPStart Encoding = omit > .byte 3 # @TType Encoding = udata4 > .uleb128 41 # @TType base offset >...

...# %.finally_handler movl $.L__string_27, %edi xorb %al, %al call printf xorl %eax, %eax addq $56, %rsp ret .size _ZN4N0014Main5test5EN2IO6WriterEiA_l, .-_ZN4N0014Main5test5EN2IO6WriterEiA_l .Lfunc_end153: .Leh_func_end153: .section .gcc_except_table,"a", at progbits .align 4 GCC_except_table153: .byte 0x0 # Padding .Lexception153: .byte 0xFF # @LPStart format (DW_EH_PE_omit) .byte 0x0...

..._gcc_personality_v0 cleanup ... Ciao, Duncan. >> >> got some example bitcode for which you see this (or, rather, don't see this >> since the problem is that you are not seeing exception tables)? >> >> Ciao, Duncan. >> >>> >>> .section .gcc_except_table,"a", at progbits >>> .align 4 >>> GCC_except_table0: >>> .Lexception0: >>> .byte 255 # @LPStart Encoding = omit >>> .byte 3 # @TType Encoding = udata4 >>> .uleb128 41 # @TType base offset >>> .byte 3 # Call site Encoding =...

...# %e subq $8, %rsp .Llabel4: .Llabel1: callq g .Llabel2: # BB#1: # %c addq $8, %rsp ret .LBB1_2: # %u .Llabel3: addq $8, %rsp ret .size f, .-f .Leh_func_end1: .section .gcc_except_table,"a", at progbits .align 4 GCC_except_table1: .byte 0 # Padding .byte 0 # Padding .Lexception1: .byte 255...

..._string_27, %edi > xorb %al, %al > call printf > xorl %eax, %eax > addq $56, %rsp > ret > .size _ZN4N0014Main5test5EN2IO6WriterEiA_l, > .-_ZN4N0014Main5test5EN2IO6WriterEiA_l > .Lfunc_end153: > .Leh_func_end153: > .section .gcc_except_table,"a", at progbits > .align 4 > GCC_except_table153: > .byte 0x0 # Padding > .Lexception153: > .byte 0xFF # @LPStart format > (DW_EH_PE_omit) > .byte 0x0...

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

...: - { - _fdata = . ; - *(.data .data.* .gnu.linkonce.d.*) - SORT(CONSTRUCTORS) - } - .data1 : { *(.data1) } - .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } - .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } - .eh_frame : { KEEP (*(.eh_frame)) } - .gcc_except_table : { *(.gcc_except_table) } - .ctors : - { - /* gcc uses crtbegin.o to find the start of - the constructors, so we make sure it is - first. Because this is a wildcard, it - doesn't matter if the user does not - actually link against crtbegin.o; the -...

> Is it safe to say the MC work provides a (new) foundation for > implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC > work? The latter. MC stuff helps somehow though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...s not use GNU as or GNU ld, don't make certain pessimized MC/CodeGen decisions. See the patch's summary for details and various hacks I've found for multiple targets (X86/AArch/PowerPC/Mips). Now I recall the patch as I ponder on using the option to enable better garbage collection for .gcc_except_table >From the review: jhenderson said: "This looks reasonable to me, but I don't know the surrounding code well enough to be comfortable LGTM-ing it. Sorry!" pcc said: "I agree with @MaskRay that this should be a binutils-specific option. The flag -mlinker-version seems to...

....; __DTOR_LIST__ = . ; LONG (-1); LONG (-1); KEEP (*(.dtors)); KEEP (*(.dtor)); KEEP (*(SORT(.dtors.*))); LONG (0); LONG (0); KEEP (*(.fini)) /* ??? Why is .gcc_exc here? */ *(.gcc_exc) PROVIDE (etext = .); KEEP (*(.gcc_except_table)) } /* The Cygwin32 library uses a section to avoid copying certain data on fork. This used to be named ".data". The linker used to include this between __data_start__ and __data_end__, but that breaks building the cygwin32 dll. Instead, we name the section...

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 section...