llvm dev - Feb 2010 - [LLVMdev] Exception Table Padding Change

On Feb 5, 2010, at 4:00 PM, Duncan 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

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
months ago, or was this effort
ditched? 

On Feb 5, 2010, at 20:44, Bill Wendling wrote:
> On Feb 5, 2010, at 4:00 PM, Duncan 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
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Feb 5, 2010, at 6:27 PM, Garrison Venn wrote:
> 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. :-)
> 
:-) 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