<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks for sending this out.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> llvm-dev <llvm-dev-bounces@lists.llvm.org>
<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 <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [llvm-dev] [RFC] Debug sections for hot-patching LLD's ELF output<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></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">
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.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>