[NoPatch!] [lld]:What output formats should we support?

[Nick Kledzik]

On Jun 20, 2014, at 7:22 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi,
> 
> I was trying to work out the best ways of getting sensible information
> out of lld today, and noticed that the MachO output formats are rather
> non-orthogonal:
> 
> + Default/YAML/Native in LinkingContext.
> + Exe/Dylib/Object/... in MachOLinkingContext.
They are orthogonal.  The upper one is the container format (e.g. mach-o, yaml, lld-native).  
The lower is that for darwin there are some different variants.  Just like ELF has executables and DSOs.
The only way these are not independent is that the “lld-native” format is for “relocatable object” files only. 
Just like bitcode is “relocatable objects” only.


> + printAtoms, also in MachOLinkingContext
> 
> The latter isn't quite the same, because output always goes to stdout,
> and the normal object is still created, but I think it should be in
> the same uniform set.

This is purely for test cases and inspection.  It prints the atom graph after all passes are done.
It is independent of the cases above.  It has nothing to do with the real linker output.


> 
> Given that MachO supports YAML for both atoms and its own format, that
> top-level enum doesn't quite map to what we might want to output. It
> would fit better if it was:
> 
> + HostNative ( == old Default)
> + HostYAML
> + AtomNative (== old Native)
> + AtomYAML (== old YAML)
“Host” is wrong here.  lld is supposed to be a cross compiler.  Host usually means
what you are running on.  The term we’ve been using for ELF/COFF/Mach-O is 
“flavor”.  

The use of “native” in your list has two meanings.  For “HostNative” you mean
the usual format for the platform/flavor.  For “AtomNative” you mean
the binary format for lld atoms.  

I’m not a big fan of our current use of “native”.  It is supposed to be the standard
binary format for atoms. Just like LLVM IR has a textual, binary, and in-memory
representation, lld’s atom graph can be in yaml, native, or in-memory.
Having a better name for native might help clear up some of this.

Adding the forth case (e.g. mach-o as yaml), is interesting.  But I’m  not
sure who would used that mode, other that for creating test case inputs. 
The mach-o writer is set up to handle that because it always first creates an
intermediate “normalized mach-o” data structure which can then be written as
binary or yaml-encoded-mach-o.  But I don’t think the ELF and COFF writers can
do that.  They would probably need to write the output as a binary to a temp 
file then run obj2yaml to convert it to yaml.  

-Nick

> Then we could drop MachOLinkingContext's _printAtoms, and a
> hypothetical _printMachOYAML in favour of a generic "-output_filetype"
> option, much like the GNU flavour has.
> 
> Does that sound like a reasonable idea to people? I can put together a
> patch reasonably quickly if so.
> 
> Cheers.
> 
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits