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 should not need any labels, since the structure in them is self describing. But with this padding, the LSDA starts from the FDEs and the 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_func_begin1
  .long Lset1eh

Use:

   .section __DATA,__gcc_except_tab
  .align 2
GCC_except_table1:
Lexception1:
  .byte 0xFF
  .byte 0x0
  .byte 0x26
  .byte 0x3
  .byte 0x9A, 0x80, 0x80, 0x00 # This is 26 in uleb128 with leading zeros to pad it out to 4 bytes
  .set Lset1eh,Llabel1-Leh_func_begin1
  .long Lset1eh

Duncan,

Can you think of anything with this?

-bw

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.

Great! Thanks, Duncan. :slight_smile:

-bw

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. :slight_smile:

Garrison

PS: Are you still revamping the llvm exception API as you proposed a couple of months ago, or was this effort
ditched?

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.

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 :slight_smile:

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. :slight_smile:

:slight_smile: Yes, that's the idea.

PS: Are you still revamping the llvm exception API as you proposed a couple of months ago, or was this effort
ditched?

I still want to do this, but it hasn't been fully vetted or approved yet.

-bw

Will do. :slight_smile:

-bw