[llvm-dev] [RFC] Debug sections for hot-patching LLD's ELF output
Petr Hosek via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 20 18:29:39 PDT 2021
Related to naming, is there a chance that other linkers might adopt this
feature as well? If so, maybe we should avoid including "lld" in the name
and use a more generic name like .debug_linker_got and .debug_linker_plt?
On Mon, Sep 20, 2021 at 6:22 PM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> (minor quibble: I'd probably avoid using the ".debug_*" namespace for
> things that seem pretty separate from/not a clear extension to DWARF - but
> maybe there's precedent for this? Not sure)
>
> On Mon, Sep 20, 2021 at 6:06 PM bd1976 llvm via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> As mentioned Sony would like LLD to optionally emit sections that
>> describe the GOT and PLT.
>>
>> The proposed binary format of these sections is as follows:
>>
>> .debug_lld_got
>> ==============
>>
>> The .debug_lld_got section contains a GOT description. The GOT
>> description begins with a header composed of the following fields:
>>
>> length (uleb)
>> - The length in bytes of the GOT description not including the length
>> field itself.
>> - This allows for padding to be added to the section, useful for purposes
>> such as slop for incremental linking.
>> - The value cannot exceed Elf_Off.
>>
>> version (uleb)
>> - The version of the description information.
>> - Currently, 0.
>> - The value cannot exceed Elf_Word.
>>
>> The header is then followed by list of entry descriptions.
>> Each entry description describes the GOT entry with the same index.
>> Each entry description starts with three ulebs:
>>
>> - The first uleb gives the number of ulebs used by this description (so
>> that the description can be skipped if the category isn't understood). The
>> value cannot exceed Elf_Word.
>> - The second uleb gives the number of GOT slots* used by this GOT entry.
>> The value cannot exceed Elf_Word.
>> - The third uleb encodes the category of the GOT entry. The value cannot
>> exceed Elf_Word.
>>
>> * Except for GOT_CAT_PADDING entries where this field gives the number of
>> bytes of padding (the value cannot exceed Elf_Off) not the number of GOT
>> slots.
>>
>> A category encoding can specify multiple associated arguments. Argument
>> interpretation is specified by the encoding. If an encoding requires
>> arguments, the bytes for those follow the bytes for the second uleb in the
>> entry description.
>>
>> Categories are:
>>
>> Encoding Argument * Size (slots)
>> Notes
>> GOT_CAT_UNKNOWN none 1
>> Unknown area of the GOT.
>> GOT_CAT_PADDING none <variable>
>> Padding between GOT regions.
>>
>> The size field gives the padding size in bytes not the number of GOT slots.
>> GOT_CAT_GOTPLT_HEADER none <target dependent>
>> The .got.plt header. x86_64 size = 3 slots.
>> GOT_CAT_GOT symbol index 1
>> Normal entry for a symbol.
>> GOT_CAT_PLTGOT symbol index 1
>> .got.plt Entry for a PLT reference to a symbol.
>> GOT_CAT_IGOTPLT symbol index 1
>> .igot.plt entry for an ifunc.
>> GOT_CAT_IGOTCANONICAL symbol index 1
>> GOT entry for canonical PLT entry for non-preemptible ifunc case.
>> GOT_CAT_TLSDESC symbol index 2
>> GOT entry for a TLSDESC slot.
>> GOT_CAT_TLS_GD symbol index 2
>> GOT entry for a GD TLS reference.
>> GOT_CAT_TLS_LD none 2
>> GOT entry for tls_index structure for an LD TLS reference.
>> GOT_CAT_TLS_IE symbol index 1
>> GOT entry for a IE TLS reference.
>> GOT_CAT_PPC64_V2_ABI_TLSLD_GOT_OFF symbol index 1
>> PPC64 specific TLSLD GOT slot.
>>
>> .debug_lld_plt
>> ==============
>>
>> The .debug_lld_plt section contains a PLT description. A PLT description
>> begins with a generic header composed of the following 3 ulebs:
>>
>> length (uleb)
>> - The length in bytes of this PLT description not including the length
>> field itself.
>> - This allows for padding to be added to the section, useful for purposes
>> such as slop for incremental linking.
>> - The value cannot exceed Elf_Off.
>>
>> version (uleb)
>> - The version of this description information. Currently, 0. The value
>> cannot exceed Elf_Word.
>>
>> type (uleb)
>> - The type of the PLT being described.
>> - This affects the interpretation of the remaining description.
>> - Currently, only PLT_FIXSZ_ENT(value = 0) is defined for describing PLT
>> sections composed of a header and N fixed size entries.
>> - The value cannot exceed Elf_Word; although, currently as there is only
>> one value specified a smaller representation is sufficient.
>>
>> PLT_FIXSZ_ENT interpretation
>> Following the generic header is the PLT_FIXSZ_ENT description header
>> which is composed of the following 2 ulebs:
>>
>> PLT header size (uleb)
>> - The size of the PLT header in bytes.
>> - The value cannot exceed Elf_Off.
>>
>> PLT entry size (uleb)
>> - The size of a PLT entry.
>> - The value cannot exceed Elf_Word.
>>
>> The header is then followed by list of entry descriptions.
>> - Each entry description is a single uleb and describes the PLT entry
>> with the same index.
>> - The value of the uleb gives the index of the associated GOT entry.
>> - The value cannot exceed Elf_Off.
>>
>> In addition to allowing hot-patching tools to work with the GOT and PLT
>> the information in these sections is of use to any tool that needs to
>> display information on the GOT and PLT sections. For example, debuggers and
>> binary tools synthesize labels of the form <symbol>@plt to label the PLT
>> sections. The information in these sections could be used to simplify such
>> tasks.
>>
>> On Wed, Sep 15, 2021 at 3:51 AM bd1976 llvm <bd1976llvm at gmail.com> wrote:
>>
>>> 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.
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210920/8aa2d6b8/attachment.html>
More information about the llvm-dev
mailing list