elf2yaml document structure, for dynamic symbols

I’m adding support for elf dynamic symbols in yaml2obj/obj2yaml. I’m seeking opinions about how to model dynamic symbols (and symbols in general) in the yaml structure. Currently, symbols in elf are represented by a top level Symbols key, within which symbols are grouped by binding type (Global, Weak, Local). The simplest thing to do would be to mirror this structure to a DynamicSymbols (or SymbolsDynamic). Is there other ways people would like to see this structure represented? Saleem suggested symbols be modeled more closely to the elf spec, and that the binding type should be represented as an attribute on each symbol, not as a grouping. For comparison, coff and macho both appear to represent the file format more directly, without much (any?) added abstraction.

Short pseudo example of the current symbol structure:

Symbols:
Global:

  • Name: …
    Type: …
    Section: …


Weak:

  • Name: …
    Type: …
    Section: …


Local:

  • Name: …
    Type: …
    Section: …

thanks,
Dave

I don’t have a strong opinion on this. yaml2obj was there when I joined to the project, and we are not using it for ELF in lld to test lld’s features anyway, so I’m not really a user of the bool. But, I wonder why you want to add the new feature to yaml2obj. Maybe, explaining your motivation would help others understand your problem.

I wonder why you want to add the new feature to yaml2obj. Maybe, explaining your motivation would help others understand your problem.

Thanks for the cue! I am using yaml2obj to generate stub dynamic libraries.

> I wonder why you want to add the new feature to yaml2obj. Maybe,
explaining your motivation would help others understand your problem.

Thanks for the cue! I am using yaml2obj to generate stub dynamic libraries.

Can't you do that by generating a small assembly file and compile & link it
to a .so?

Can’t you do that by generating a small assembly file and compile & link it to a .so?

I could, though I admit I haven’t consider that approach. Thanks for the suggestion. If there is opposition to adding support for dynamic symbols, then I will try the assembly+linker approach, but if I can add the support for dynamic symbols, then I’ll continue with yaml2obj, at least for now. We also had a test case we wanted to write using obj2yaml but couldn’t because of the lack of dynamic symbols.

I’m not really pushing back, and I’m not opposing to your idea to add the feature to obj2yaml/yaml2obj, but if you can do what you want to do using existing tools, why do you want to write new code?

For tests, you might be able to llvm-objdump which can dump .dynsym contents. obj2yaml and yaml2obj are the tools to serialize and de-serialize a binary file, so if you don’t need a round-trip conversion, other tool might fit better.