[LLVMdev] Exception Table Padding Change

Bill Wendling wendling at apple.com
Fri Feb 5 14:23:31 PST 2010


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





More information about the llvm-dev mailing list