[llvm-dev] Proposal for address-significance tables for --icf=safe
Peter Smith via llvm-dev
llvm-dev at lists.llvm.org
Thu May 24 02:34:16 PDT 2018
On 23 May 2018 at 23:07, Peter Collingbourne <peter at pcc.me.uk> wrote:
>
>
> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk>
> wrote:
>>
>> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org>
>> wrote:
>>>
>>> Hello,
>>>
>>> I think that the approach of using a section to record address
>>> significance is a good one. I'm guessing it will have its own section
>>> type and format? If it does would it make sense to try and submit this
>>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it
>>> could be potentially useful for other linkers, for example gold?
>>
>>
>> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence
>> of ULEB128-encoded symbol table indexes that are address-significant).
>>
>> I think it makes sense for this to eventually be part of the generic ABI,
>> and I will send a proposal to generic-abi. As I mentioned in my reply to
>> James Knight, I don't think we should block on getting a section number
>> assignment, but we can at least incorporate any design feedback from that
>> proposal.
>
>
> I've sent the proposal:
> https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4
>
> Peter
Thanks. I agree we shouldn't require it to be in the GABI before
proceeding. I think making the proposal more visible to the wider
community will already have been worthwhile.
In the absence of a GABI defined way to tell if an ELF processing tool
may have broken the symbol table order, one possible option might be
to reserve the first entry as some hash of the symbol names that would
be different if the indexes into the symbol table were changed. This
does make it more complicated for an object processing tool to handle
the section though.
Peter
More information about the llvm-dev
mailing list