[LLVMdev] Status of YAML IO?
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
Wouldnt it be hard to get the source / line information right if the
linker tries to write the debug information ?
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
More information about the llvm-dev