tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] [ RFC] About packing two infos in a long


From: Thomas Preud'homme
Subject: [Tinycc-devel] [ RFC] About packing two infos in a long
Date: Tue, 6 Nov 2012 12:02:53 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Greetings everyone,

while working on adding support for R_ARM_THM_JUMP24 to a PLT entry, I needed 
to store an extra information for some symbols about the nature of the call 
sites of a PLT entry. Since most symbols don't have a PLT entry, I was 
reluctant in adding even a byte for all symbols in a set of object file. Then I 
realized bit 0 of entries in the got_offsets array (in TCCState) is always 0 
and could be reused for my purpose.

Currently (see attached patch 0002-Generate-PLT-thumb-stub-only-when-
necessary.patch), I reuse the bit 0 without using bitfields. This has the 
advantage of being able to reuse put_got_offset() function by changing the 
assignment of the value with a bit ORing but doesn't mark explicitely to the 
compiler what's going on. On the other hand, I could use bitfields but that 
would require some more modifications to put_got_offset to be able to set a 
got_offset and/or the bit 0.

Note that in both cases all access to got_offset needs to be changed: if 
bitfields is used the value of got_offset needs to be shifted by one bit to the 
left, else, the value needs to be ANDed with -2 to ignore bit 0.

What's your opinion about it? What's the best approach? Is there another one 
possible? (I initially thought about storing the extra information in a hash 
table but it requires to add an hashtable implementation while I could reuse 
the unused bit of got_offsets).

Best regards,

Thomas Preud'homme

Attachment: 0001-Support-R_ARM_THM_JUMP24-relocation-to-plt.patch
Description: Text Data

Attachment: 0002-Generate-PLT-thumb-stub-only-when-necessary.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]