[llvm-dev] [RFC] Debug sections for hot-patching LLD's ELF output

[bd1976 llvm via llvm-dev]

Hi All,

Sony maintains a downstream patchset to optionally emit additional
informational sections to the ELF output file created by LLD. These
sections describe LLD's output and the transformations applied during
Linking. These additional sections are used with the static symbol
table (.symtab) to facilitate the operation of hot-patching tools.

Our preferences are that:

- The information required for hot-patching is stored in the ELF
  output file as ELF sections, as opposed to being emitted into
  auxiliary files. Otherwise, customers have to adjust their processes
  to keep the ELF output file and auxiliary files together when
  packing/moving the ELF output file and ensure they are correctly
  matched.

- These metadata sections are created by LLD, rather than derived via
  a post-link procedure. Performance is important, as customers want
  to be able to enable the emission of hot-patching metadata by
  default, and having LLD directly emit the required sections is more
  efficient and a simpler work-flow.

The contents of these sections could be seen as debugging information
for the linking process. Certainly, we would want to handle these
sections with the same rules that apply to debugging sections when
manipulating a linked ELF with binary utility tools. For that reason
the sections are all named .debug_lld_* e.g. .debug_lld_linkmap.

Currently, Sony would like to emit the following sections and we
believe that they are generally useful:

- A linkmap section that contains a subset of the information contained
  in a linker -Map file. This section specifies the linked address for
  each input section.

- A section which specifies the list of wrapped symbols.

- A section that describes the GOT. This provides:
-- A category for each entry, examples: GOT entry, PLTGOT entry, TLS GD
   entry, LD TLS tls_index structure entry etc..
-- A slot index at which the entry starts.
-- A size for the entry, as GOT entries may take more than one GOT
   slot (e.g. a TLS GD entry takes two slots).
-- An optional static symbol index to which the GOT entry is associated
   (some entries e.g. the LD TLS tls_index structure are not associated
   with a particular symbol).

- A section describing the PLT. This section needs to be somewhat
  flexible to deal with the many different PLT's that exist on ELF
  toolchains. However, for a fixed size entry PLT description the section
  will supply:
-- Which range of bytes comprises the PLT header.
-- The size of a PLT entry.
-- For each PLT entry, the GOT slot index of the associated GOT entry.
   Combined with the information on GOT entries from the GOT description
   section this allows for the association of a PLT entry with a symbol.

Similar to DWARF sections these are non-alloc sections. They are encoded
as sequences of ULEB128 values. As these are debugging sections, not core
ELF sections, a compact representation is justifiable, even if the encoding
is more complex.

In order to anchor this discussion I have created
https://reviews.llvm.org/D109804
which contains a prototype implementation of the linkmap section referenced
above.

I would like to ascertain whether the LLVM community would be
supportive of adding the ability to generate such sections to LLD?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210915/98f4a0f9/attachment.html>