[llvm-dev] elf2yaml document structure, for dynamic symbols

[Dave Lee via llvm-dev]

> 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.

On Wed, Nov 1, 2017 at 11:29 AM, Rui Ueyama <ruiu at google.com> wrote:

> 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.
>
> On Wed, Nov 1, 2017 at 10:43 AM, Dave Lee <davelee.com at gmail.com> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/9e22c234/attachment.html>