[llvm-dev] Proposal for address-significance tables for --icf=safe

[Peter Collingbourne via llvm-dev]

On Thu, May 24, 2018 at 2:34 AM, Peter Smith <peter.smith at linaro.org> wrote:

> 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.
>

That does seem reasonable if we can't get agreement on the gABI side. It
can probably just be a hash of the contents of .symtab plus the contents of
the linked .strtab, and we can store it in the addrsig section's sh_info to
avoid taking up space in the section.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180524/8cb72a41/attachment.html>