[llvm-dev] [RFC] Adding support for dynamic entries in yaml2obj (original) (raw)

Armando Montanez via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 16 11:13:15 PST 2019

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:

DynamicSymbols:

Global:

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>

More information about the llvm-dev mailing list