[LLVMdev] Status of YAML IO?

[Shankar Easwaran]

Hi Nick,

I had a few questions :-

1) Is there a way to validate that the input file is of a valid format, 
thats defined by the YAML Reader ?
2) How are you plannning to represent section groups in the YAML ?
3) How are you planning to support Atom specific flags ? Is there a way 
already ?
     (This would be needed to group similiar atoms together)
4) Are you planning to support representing shared libraries too in this 
model ?
5) are you planning to support dwarf information too ?

Thanks

Shankar Easwaran

On 10/29/2012 9:26 PM, Nick Kledzik wrote:
> Michael,
>
> To validate the refactor of YAML Reader/Writer using YAML I/O.  I 
> updated all the test cases to be compatible with YAML I/O.  One issue 
> that was a gnarly was how to handle the test cases with archives. 
>  Currently, we have test cases like:
>
> ---
> atoms:
>     - name: foo
>      # more stuff
> ---
> archive:
>    - name bar.o
>      atoms:
>  - name:  bar
>         # more stuff
>
>
> This sort of weak/dynamic typing is hard to using with YAML I/O which 
> enforces stronger typing which helps it do better error checking.   
> The core of the problem is when a new document is started, we don't 
> know what kind of file it is going to be, to know what keys are legal. 
>   I first looked into used tags to specify the document type.  For 
> example:
>
> --- !archive
> members:
>    - name: bar.o
>    # more stuff
>
> But after modifying YAMLParser to make that the tag available, then 
> trying to figure out how to make the tag actionable in the trait, I 
> realized that for maps, the tag is just like another key.  So, if 
> every client agreed that the first key/value was a particular key name 
> (e.g. tag:  type) which YAML I/O already supports, then there is no 
> need for tags and no need for an additional mechanism in YAML I/O.
>
> So, I know have the traits set up to support archives assuming the 
> first (option) key of each document type read by lld will be "kind:". 
>  The archive-basic.objctxt case now looks like:
>
> # RUN: lld-core %s | FileCheck %s
>
> #
> # Tests archives in YAML. Tests that an undefined in a regular file 
> will load
> # all atoms in select archive members.
> #
>
> ---
> defined-atoms:
>     - name:              foo
> type:              code
>
> undefined-atoms:
>     - name:              bar
>
> ---
> kind:                   archive
> members:
>   - name:               bar.o
> content:
> defined-atoms:
>   - name:              bar
>     scope:             global
>     type:              code
>
>   - name:              bar2
>     type:              code
>
>   - name:               baz.o
> content:
> defined-atoms:
>   - name:              baz
>     scope:             global
>     type:              code
>
>   - name:              baz2
>     type:              code
> ...
>
> # CHECK:       name:       foo
> # CHECK-NOT:  undefined-atoms:
> # CHECK:       name:       bar
> # CHECK:       name:       bar2
> # CHECK-NOT:   name:       baz
> # CHECK:       ...
>
> My thinking is that we can extend this to support embedded 
> COFF/ELF/MachO in yaml by using new kind values.  For example:
>
> ---
> kind:                   object-coff
> header:
>    # stuff
> sections:
>    # stuff
> symbols:
>    # stuff
> ...
>
> The MappingTrait<const ld::File*> will look at the kind value and 
> switch off it.   We just need an external function (per file format) 
> which can be called with the same mapping() parameters which will do 
> the io.map*() calls and have traits for platform specific types, 
>  which turns the yaml into an in-memory binary object, then runs the 
> Reader to return a File*.  I'll be prototyping this approach for mach-o.
>
> -Nick
>
>
> On Oct 25, 2012, at 9:59 AM, Sean Silva wrote:
>>> To better understand how a client would use YAML I/O.  I've 
>>> completely rewritten the ReaderYAML and WriterYAML in lld to use 
>>> YAML I/O.  The source code is now about half the size.  But more 
>>> importantly,  the error checking is much, much better and any time 
>>> an attribute (e.g. of an Atom) is changed or added, there is just 
>>> one place to update the yaml code instead of two places (the reader 
>>> and writer).
>>
>> Fantastic!
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121030/7b2b134a/attachment.html>