<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 2:34 AM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 23 May 2018 at 23:07, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
><br>
><br>
> On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
> wrote:<br>
>><br>
>> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <<a href="mailto:peter.smith@linaro.org">peter.smith@linaro.org</a>><br>
>> wrote:<br>
>>><br>
>>> Hello,<br>
>>><br>
>>> I think that the approach of using a section to record address<br>
>>> significance is a good one. I'm guessing it will have its own section<br>
>>> type and format? If it does would it make sense to try and submit this<br>
>>> to the GABI <a href="https://groups.google.com/forum/#!forum/generic-abi" rel="noreferrer" target="_blank">https://groups.google.com/<wbr>forum/#!forum/generic-abi</a> as it<br>
>>> could be potentially useful for other linkers, for example gold?<br>
>><br>
>><br>
>> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence<br>
>> of ULEB128-encoded symbol table indexes that are address-significant).<br>
>><br>
>> I think it makes sense for this to eventually be part of the generic ABI,<br>
>> and I will send a proposal to generic-abi. As I mentioned in my reply to<br>
>> James Knight, I don't think we should block on getting a section number<br>
>> assignment, but we can at least incorporate any design feedback from that<br>
>> proposal.<br>
><br>
><br>
> I've sent the proposal:<br>
> <a href="https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4" rel="noreferrer" target="_blank">https://groups.google.com/<wbr>forum/#!topic/generic-abi/<wbr>MPr8TVtnVn4</a><br>
><br>
> Peter<br>
<br>
</span>Thanks. I agree we shouldn't require it to be in the GABI before<br>
proceeding. I think making the proposal more visible to the wider<br>
community will already have been worthwhile.<br>
<br>
In the absence of a GABI defined way to tell if an ELF processing tool<br>
may have broken the symbol table order, one possible option might be<br>
to reserve the first entry as some hash of the symbol names that would<br>
be different if the indexes into the symbol table were changed. This<br>
does make it more complicated for an object processing tool to handle<br>
the section though.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>