search for: pr5004

...(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. Looks ok for me, but please postpone the patch until stuff pr5004 would land (it only requires testing on darwin), so we won't need to do the testing several times, neither have the merge conflicts :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

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