[llvm-dev] [RFC] Adding support for dynamic entries in yaml2obj

[Armando Montanez via llvm-dev]

The goal of this proposal is to introduce a new type of YAML section for
yaml2obj that allows the population of ELF .dynamic entries via a list of
tag and value pairs. These entries are interpreted (and potentially
validated) before being written to the .dynamic section. The simplest way
to satisfy this requirement is for all dynamic entry values to be numeric
values. Unfortunately, this inherently prevents entries like DT_SONAME,
DT_NEEDED, DT_RPATH, and DT_RUNPATH from being specified alongside dynamic
symbols due to the design of yaml2obj.


This proposal introduces three ways to input a value for a dynamic entry.
For a given dynamic tag, one or more of these methods of setting a value
may be permitted. All of these cases are illustrated later with an example.


1. For dynamic entry strings that belong in .dynstr, the string itself can
be used as the value for an entry. (ex. DT_SONAME, DT_NEEDED, DT_RPATH, and
DT_RUNPATH)


2. A section name can be used in place of an address. In this case, the
value of the dynamic entry is the sh_addr of the specified section. (ex.
DT_STRTAB, DT_SYMTAB, DT_HASH, DT_RELA, and others)


3. A value can be specified using hexadecimal or decimal (or other bases
supported by `StringRef::to_integer()`). (ex. DT_STRSZ, DT_SYMENT,
DT_RELAENT, and others)


Here's an example to illustrate this design:


!ELF

FileHeader:

 Class:           ELFCLASS64

 Data:            ELFDATA2LSB

 Type:            ET_DYN

 Machine:         EM_X86_64

Sections:

 - Name: .dynsym

   Type: SHT_DYNSYM

   Address: 0x1000

 - Name: .data

   Type: SHT_PROGBITS

   Flags: [ SHF_ALLOC, SHF_WRITE ]

 - Name: .dynamic

   Type: SHT_DYNAMIC

   Entries:

     - Tag: DT_SONAME

       Value: libsomething.so

     - Tag: DT_SYMTAB

       Value: .dynsym

     - Tag: DT_SYMENT

       Value: 0x18

DynamicSymbols:

 Global:

   - Name: foo

     Type: STT_FUNC

     Section: .data

   - Name: bar

     Type: STT_OBJECT

     Section: .data


The final section is of type SHT_DYNAMIC, and the "Entries" key illustrates
the proposed addition. Walking through the three dynamic entries,


1. DT_SONAME: The value of this entry is a string that will be inserted
into the dynamic string table (.dynstr) alongside the symbol names
specified in DynamicSymbols. This is possible due to the nature of .dynstr
being represented as a StringTableBuilder, and that .dynamic is linked to
.dynstr by default. If the .dynamic section had been linked to a section
other than .dynstr, the value of this entry would have to be a number (the
offset of the string in the linked string table) rather than a string.


2. DT_SYMTAB: This tag may either be a numeric address or a valid section
name, and this example illustrates the option of using the name of a
section rather than the address. This resolves to 0x1000 since .dynsym is
declared with an address of 0x1000. It would have been equally valid to
make this entry have a value of 0x1000, but doing so would mean that
changes to .dynsym's address would need to be manually updated in the
dynamic entry. It's also worth noting that in the case of DT_SYMTAB it
wouldn't be too difficult to infer this.


3. DT_SYMENT: This tag is restricted to only having numeric values. This
entry could easily be inferred as well.


Note that it doesn’t make sense for DT_SYMENT to be any sort of string, so
it is restricted to only being populated with a numeric value. Similarly,
it doesn’t make sense for the value of DT_SONAME to ever be interpreted as
the name of a section. Though at least one input method is required for a
given dynamic tag, it’s typically the case that not all three are valid. It
should also be possible to specialize upon certain tags for convenience.
For example, DT_PLTREL could be specialized to allow “REL” and “RELA” to be
used as values rather than requiring the values be entered in hexadecimal.
Evaluating the needs for every dynamic tag isn’t within the scope of this
proposal, so any tag without a specialization defaults to permitting
numeric values or the name of a valid section (that is later converted to
an address).


Some dynamic tags have strict enough constraints that they can be inferred.
This limited set of dynamic tags could treat “Value” an optional field
since the value can be inferred from other parts of an ELF file. This isn’t
a requirement for me, though it's something I'd certainly like to have.


I began working on a patch here, and it will later be updated to reflect
the RFC:

https://reviews.llvm.org/D56569


Best,

Armando
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/cd8120cf/attachment.html>