[llvm-commits] [llvm] r97078 - in /llvm/trunk/lib/CodeGen/AsmPrinter: DwarfException.cpp DwarfPrinter.cpp DwarfPrinter.h

[Duncan Sands]

Hi Chris,

>> LLVM puts padding bytes in the __gcc_except_tab section after the
>> GCC_except_table label but before the Lexception, which the FDE references.
>> This causes problems as the FDE does not point to the start of an LSDA chunk.
>>
>> Use an unnormalized uleb128 for the call-site table length that includes the
>> padding.
>
> Ok, I don't really understand, but:

unwind info is output in a table.  The *end* of the table has to be 4 byte
aligned.  The size of the table is output immediately before the table in a
variable length format.

How does GCC align the end of the table?  It inserts alignment bytes *inside*
the table itself.  This changes the size of the table.  Since the size is
output in a variable length format just before the table, if the number of
bytes needed to output the size increases then the start of the table moves.
This means that the end of the table may no longer be aligned!  If this
happens, then GCC recalculates the number of alignment bytes to use,
recalculates the table size, and if the start of the table moved again it
tries yet again, and so on, in the hope that the result will one day stabilize.

I didn't like that method, so used a different one: LLVM outputs the alignment
bytes before the table (and before the table size) - problem solved.  Except
that this was always a bit dubious - what if something is expecting the *start*
of the table to be aligned too?  (GCC aligns the start)  But it seemed to work
fine, so I just did it.  However an Apple "linker guy" noticed it and came up
with a clever suggestion that gives the best of both worlds: put the alignment
padding inside the table size itself, by using extra redundant bytes when
specifying the size.  The variable length format being used (uleb128) does not
*require* you to output a number using the minimum possible number of bytes,
you can always use more.

That's what Bill implemented (unfortunately the meat of the change was hidden
by the large number of cosmetic tweaks), so now the start of the table is
aligned, the end of the table is aligned, and we can feel pleasantly superior
to GCC because we don't need a horrible loop :)

Ciao,

Duncan.