[LLVMdev] Status of YAML IO?

Shankar Easwaran shankare at codeaurora.org
Tue Oct 30 11:10:55 PDT 2012

Thanks for the reply Nick.

1) Is there a way to validate that the input file is of a valid format, 
thats defined by the YAML Reader ?
> Do you mean different than if the yaml reader accepts it? Tons of 
> files will be valid yaml syntactically.  It is the semantic level 
> checking that is hard, and that is what YAML I/O does.
Yes, if the YAML reader accepts it and figures out that its not the 
format what ReaderYAML needs.

>> 2) How are you plannning to represent section groups in the YAML ?
> You mean the ELF concept of section groups in YAML encoded ELF?   The 
> YAML encoding of ELF (or COFF or mach-o) does not know anything deeper 
> about the meaning of the files.  It is just the bytes from each 
> section and the entries in the symbol table.  If a section group is a 
> section of bytes which are interpreted as an array of symbol/section 
> indexes, then the ELF encoded YAML just has the raw bytes for the section.

>> 3) How are you planning to support Atom specific flags ? Is there a 
>> way already ?
>>     (This would be needed to group similiar atoms together)
> It is still an open question how to support platform specific Atom 
> attributes.  As much as possible we'd like to expand the Atom model to 
> be a superset of all the platform specific flags.  But there are some 
> attributes that are very much tied to one platform.  One idea is to 
> just add a new Reference which has no target but its kind (and maybe 
> addend) encode the platform specific attributes.  The Reference kind 
> is already platform specific.

How about if the atom flags could be overridden ? The Atom flag could 
have a MIN/MAX and anything above the MAX or lower than the MIN are 
platform specific, like how its dealt with section indexes ?

>> 4) Are you planning to support representing shared libraries too in 
>> this model ?
> Yes, we already support shared library atoms in yaml.
Sorry didnt check that.
>> 5) are you planning to support dwarf information too ?
> Debugging information is another big open question.  The dwarf format 
> is very much tied to the section model.  Not only is the debug 
> information put is sections with special names, but the dwarf debug 
> into references code by its address in the .o files (the Atom model 
> does not model addresses).    I'm sure the lldb guys have some ideas 
> on direction of where they would like debug information to go.  It may 
> be that the Atom model has a different representation for debug info. 
>  And when generating a final linked image you can choose the debug 
> format you want.  A Writer could convert the debug info to dwarf if 
> requested.
Wouldnt it be hard to get the source / line information right if the 
linker tries to write the debug information ?


Shankar Easwaran

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

More information about the llvm-dev mailing list