<div dir="ltr">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.<br></div>