[LLVMdev] Status of YAML IO?

[Nick Kledzik]

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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121029/3d3ace69/attachment.html>