[LLVMdev] [lld] Representation of lld::Reference with a fake target

[Simon Atanasyan]

I definitely do not suggest to refuse the atom/reference model. My
idea is to stop considering YAML/Native formats as *union* of all
target specific properties but allow target specific code to arbitrary
extend YAML/Native formats. Like MIPS, ARM, X86 etc can extend ELF
format. That approach can be implemented by two ways. The first one is
to move real YAML/Native read/writing to the target specific code, so
lldNative and lldYAML define only common upper-level structures for
both formats and provide some common routines for reading/writing. The
second way is to allow atoms and references to keep sets of target
specific attributes in some general form like key->value dictionaries.

On Sat, Feb 7, 2015 at 6:52 PM, Shankar Easwaram <shankarke at gmail.com> wrote:
> We are modeling target specific functionally using references, Doesn't your idea defeat the purpose of the atom model? Atoms are mostly target neutral and yaml/native format represents just an atom. Having a derived class for atoms will have a impact on the testing method with lld IMO.
>
> We could continue to model using references in my opinion and add some meta data information in the atom where references are not able to model.
>
>
>> On Feb 7, 2015, at 02:36, Simon Atanasyan <simon at atanasyan.com> wrote:
>>
>> My 2c: maybe we should not try to put all target specific object file
>> formats into the single YAML/Native representation. Let's define an
>> universal formats of file "header" for YAML/Native representation and
>> probably some top-level structures common for all target and allow
>> target specific code to arbitrary extend these formats. For example
>> code in the ReaderWriter/ELF will know how to convert ELF object files
>> into the YAML/Native form. In that case we get in fact some
>> incompatible YAML/Native formats for ELF, PECOFF, MachO etc. But I
>> think it is not a problem.

-- 
Simon Atanasyan