search for: uleb128

...ign 4 GCC_except_table153: .byte 0x0 # Padding .Lexception153: .byte 0xFF # @LPStart format (DW_EH_PE_omit) .byte 0x0 # @TType format (DW_EH_PE_absptr) .uleb128 28 # @TType base offset .byte 0x3 # Call site format (DW_EH_PE_udata4) .uleb128 26 # Call site table size .long .Llabel291-.Leh_func_begin153 # Region star...

...# Padding .byte 0 # Padding .Lexception1: .byte 255 # @LPStart format (omit) .byte 0 # @TType format (absptr) .uleb128 15 # @TType base offset .byte 3 # Call site format (udata4) .uleb128 13 # Call site table size .long .Llabel1-.Leh_func_begin1 # Region start .long ....

...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 # Call site Encoding = udata4 .uleb128 39 # Call site table length .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start .long .Lset0 .Lset1 = .Ltmp0-.Leh_func_begin0 # Region length...

....byte 0x0 # Padding > .Lexception153: > .byte 0xFF # @LPStart format > (DW_EH_PE_omit) > .byte 0x0 # @TType format > (DW_EH_PE_absptr) > .uleb128 28 # @TType base offset > > .byte 0x3 # Call site format > (DW_EH_PE_udata4) > .uleb128 26 # Call site table size > .long .Llabel291-.Leh_func_begin153...

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

...estigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128 variable-length encoding, whereas LLVM uses fixed-size 32-bit values (udata4). Switching to ULEB128 is a large size improvement. For instance, I'm currently playing with Qt5, and the libQt5Core.so binary is about 4MB with...

...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 = udata4 > .uleb128 39 # Call site table length > .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start > .long .Lset0 > .Lset1 = .Ltmp0-.Leh_func_beg...

...3.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 0x1 # call-site format (uleb128) 114 .uleb128 .LLSDACSE2-.LLSDACSB2 # Call-site table length 115 .LLSDACSB2: 116 .uleb128 0x0 # region 0 landing pad 117 .uleb128 0...

...r3 sub sp, fp, #4 ldmfd sp!, {fp, lr} bx lr .L10: .align 2 .L9: .word _ZTIi .word .LC0 .global __gxx_personality_v0 .personality __gxx_personality_v0 .handlerdata .align 2 .LLSDA6: .byte 0xff .byte 0 .uleb128 .LLSDATT6-.LLSDATTD6 .LLSDATTD6: .byte 0x1 .uleb128 .LLSDACSE6-.LLSDACSB6 .LLSDACSB6: .uleb128 .LEHB0-.LFB6 .uleb128 .LEHE0-.LEHB0 .uleb128 .L7-.LFB6 .uleb128 0x1 .uleb128 .LEHB1-.LFB6 .uleb128 .LEHE1-.LEHB1 .uleb128 0 .uleb128 0 .uleb128 .L...

...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 = udata4 >> .uleb128 39 # Call site table length >> .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start >> .long .Lset0 >> .Lset1...

Thank you Frits! I noticed the following lines in the dwarf output (run with -O2): .uleb128 40 # Offset .byte 134 # DW_CFA_offset + Reg (6) .uleb128 4 # Offset .byte 135 # DW_CFA_offset + Reg (7) .uleb128 3 # Offset .byte 131 # DW_CFA_offset + Reg (3...

...ot;, s); } } GCC outputs this: [Irk:llvm] gcc-4.2 -S -o - -dA t.cpp -O3 .text .align 4,0x90 .globl __Z3foov __Z3foov: . . . LEHB0: call __Z3bazv LEHE0: . . . GCC_except_table0: LLSDA8: .byte 0xff # @LPStart format (omit) .byte 0x9b # @TType format (indirect pcrel sdata4) .byte 0x25 # uleb128 0x25; @TType base offset .byte 0x3 # call-site format (udata4) .byte 0x1a # uleb128 0x1a; Call-site table length .set L$set$0,LEHB0-LFB8 .long L$set$0 # region 0 start .set L$set$1,LEHE0-LEHB0 .long L$set$1 # length .set L$set$2,L6-LFB8 .long L$set$2 # landing pad .byte 0x1 # uleb128 0x1;...

...GCC_except_table* labels are now different. It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: .section __DATA,__gcc_except_tab .align 2 GCC_except_table1: .byte 0x0 .byte 0x0 .byte 0x0 Lexception1: .byte 0xFF .byte 0x0 .byte 0x26 .byte 0x3 .byte 0x1A .set Lset1eh,Llabel1-Leh...

...gt; 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 = udata4 >>> .uleb128 39 # Call site table length >>> .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start >>> .long .Lset0 >>> .Lset1 = .Ltmp0-.Leh_func_begin0 # Region length >>> .l...

...n Sands wrote: > Hi Bill, > >> It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: > > this sounds like a good idea to me. > Great! Thanks, Duncan. :-) -bw

...t match then the next action to consider is offset -3 from here (0x7d), i.e. it will next examine 119 .byte 0x1 # Action record table 120 .byte 0x0 i.e. it will try and match with _ZTIb. If this doesn't match then it is all over (0x0). > 116 .uleb128 0x0 # region 0 landing pad > 117 .uleb128 0x5 # action > 118 .LLSDACSE2: > 119 .byte 0x1 # Action record table > 120 .byte 0x0 > 121 .byte 0x2 > 122 .byte 0x7d > 123 .byte 0x3 >...

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports

...nator: 0x100 if (i++ < N) { foo(); // discriminator: 0x200 if (i++ < N) { foo(); // discriminator: 0x300 } } } The cost of this change would be increased debug_line size because: 1. we are recording more discriminators 2. discriminators become larger and will take more ULEB128 encoding. The benefit is that the sample pgo profile can accurately represent the code execution frequency. And we do not need to introduce new building blocks to debug info. Comments? Thanks, Dehao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists....

Hi Bill, > It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: this sounds like a good idea to me. Ciao, Duncan.

Hi Bill, Just to verify that I understand correctly, the proposal should not have any affect on pre-existing code since we already call readULEB128(...) for the call-site table length. High bit set for 3 bytes results in 4 byte read as per uleb128. This is obvious now that I've taken time to write this, but hey if nothing else it helps the list. :-) Garrison PS: Are you still revamping the llvm exception API as you proposed a couple of m...