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

[Shankar Easwaram]

I agree with you that we should consider one of the below approaches.



> On Feb 8, 2015, at 05:08, Simon Atanasyan <simon at atanasyan.com> wrote:
> 
> 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