<div dir="ltr"><div>Thanks Peter,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 16, 2021 at 9:30 AM Peter Smith <<a href="mailto:Peter.Smith@arm.com" target="_blank">Peter.Smith@arm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal"><span>Thanks for sending this out.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>My initial reaction is that this would be most useful for post linking tools. For human readable output only I expect that we’d be comfortable with existing map file output and a disassembly.</span></p></div></div></blockquote><div><br></div><div>Emitting a linkmap section is *much* more efficient than generating a -Map file. Testing with a chromium package on my windows development box, I got the following results using a build of main with <a href="https://reviews.llvm.org/D109804">https://reviews.llvm.org/D109804</a> applied: Base link = 3.524 s, With -Map = 8.441 s, With --debug-sections (for the linkmap section) = 3.910 s. Also, with the linkmap section the information is built into the ELF so you don't have the problem of tracking which -Map file goes with which ELF. Given those advantages, for some use-cases the linkmap is a superior solution - even when only humans will want to view the information.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><p class="MsoNormal"><span><u></u></span></p>
<p class="MsoNormal"><span>I have a small concern of upstream maintainability without the binary patching tools themselves. For example it may be that all we have is the llvm-readobj/llvm-objdump to textually dump the output.
It is possible that we could make modifications with corresponding changes to the text dumps that could break assumptions the binary patching tools are making. I think this is likely to be rare, but I couldn’t rule it out.</span> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><p class="MsoNormal"><span><u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>While I wouldn’t object as I think the extra debug output is not likely to need a lot of maintenance I think it would be good to get someone actively interested in binary patching or some other post-link
tool to comment.</span></p></div></div></blockquote><div><br></div><div>Unfortunately, hotpatching seems to be more of a propriety technology rather than opensource (although it would be great to be wrong and I'm hoping that someone may reply and correct me).</div><div><br></div><div>Sony and partners are interested in these sections for our downstream toolchain and we will commit to monitoring them and ensuring the format doesn't change without agreement. We could also add upstream tests that check a hex dump of the section contents for these debugging sections and which have strongly worded comments in the test noting that the format should not change without agreement from stakeholders (we actually successfully use a similar strategy in our downstream tests to flag up upstream changes for review).</div><div><br></div><div>I envision that these linker debug sections will have a version field (as DWARF sections do) which we can use to manage changes to the format of these sections.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div><p class="MsoNormal"><span><u></u></span></p>
<p class="MsoNormal"><span>Peter<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>bd1976 llvm via llvm-dev<br>
<b>Sent:</b> 15 September 2021 03:52<br>
<b>To:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [llvm-dev] [RFC] Debug sections for hot-patching LLD's ELF output<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi All,<br>
<br>
Sony maintains a downstream patchset to optionally emit additional<br>
informational sections to the ELF output file created by LLD. These<br>
sections describe LLD's output and the transformations applied during<br>
Linking. These additional sections are used with the static symbol<br>
table (.symtab) to facilitate the operation of hot-patching tools.<br>
<br>
Our preferences are that:<br>
<br>
- The information required for hot-patching is stored in the ELF<br>
output file as ELF sections, as opposed to being emitted into<br>
auxiliary files. Otherwise, customers have to adjust their processes<br>
to keep the ELF output file and auxiliary files together when<br>
packing/moving the ELF output file and ensure they are correctly<br>
matched.<br>
<br>
- These metadata sections are created by LLD, rather than derived via<br>
a post-link procedure. Performance is important, as customers want<br>
to be able to enable the emission of hot-patching metadata by<br>
default, and having LLD directly emit the required sections is more<br>
efficient and a simpler work-flow.<br>
<br>
The contents of these sections could be seen as debugging information<br>
for the linking process. Certainly, we would want to handle these<br>
sections with the same rules that apply to debugging sections when<br>
manipulating a linked ELF with binary utility tools. For that reason<br>
the sections are all named .debug_lld_* e.g. .debug_lld_linkmap.<br>
<br>
Currently, Sony would like to emit the following sections and we<br>
believe that they are generally useful:<br>
<br>
- A linkmap section that contains a subset of the information contained<br>
in a linker -Map file. This section specifies the linked address for<br>
each input section.<br>
<br>
- A section which specifies the list of wrapped symbols.<br>
<br>
- A section that describes the GOT. This provides:<br>
-- A category for each entry, examples: GOT entry, PLTGOT entry, TLS GD<br>
entry, LD TLS tls_index structure entry etc..<br>
-- A slot index at which the entry starts.<br>
-- A size for the entry, as GOT entries may take more than one GOT<br>
slot (e.g. a TLS GD entry takes two slots).<br>
-- An optional static symbol index to which the GOT entry is associated<br>
(some entries e.g. the LD TLS tls_index structure are not associated<br>
with a particular symbol).<br>
<br>
- A section describing the PLT. This section needs to be somewhat<br>
flexible to deal with the many different PLT's that exist on ELF<br>
toolchains. However, for a fixed size entry PLT description the section<br>
will supply:<br>
-- Which range of bytes comprises the PLT header.<br>
-- The size of a PLT entry.<br>
-- For each PLT entry, the GOT slot index of the associated GOT entry. <br>
Combined with the information on GOT entries from the GOT description <br>
section this allows for the association of a PLT entry with a symbol.<br>
<br>
Similar to DWARF sections these are non-alloc sections. They are encoded<br>
as sequences of ULEB128 values. As these are debugging sections, not core<br>
ELF sections, a compact representation is justifiable, even if the encoding<br>
is more complex.<br>
<br>
In order to anchor this discussion I have created <a href="https://reviews.llvm.org/D109804" target="_blank">
https://reviews.llvm.org/D109804</a><br>
which contains a prototype implementation of the linkmap section referenced<br>
above.<br>
<br>
I would like to ascertain whether the LLVM community would be<br>
supportive of adding the ability to generate such sections to LLD?<br>
<br>
Thanks.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote></div></div>