[lld] r217324 - Remove dead code.

Nick Kledzik kledzik at apple.com
Tue Sep 9 17:46:25 PDT 2014


On Sep 9, 2014, at 8:30 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> On 9/8/2014 4:28 PM, Nick Kledzik wrote:
>>> I’ll be needing this or some equivalent in a few weeks when I add “debug map”[1] support to mach-o part of lld.
>>> 
>>> But translationUnitSource() is just one of a handful of File-level attributes that mach-o will need.  And these attributes are probably not useful on other platforms, so we should work out a design for this.  Some of the other File level attributes mach-o needs are: min-OS, platform (e.g. iOS simulator vs MacOSX), Objective-C flavor, Swift language version, auto linking hints, debug map from -r merging, etc.  Some possible designs:
>>> 
>>> 1) Add a method to lld::File for each attribute (e.g. t translationUnitSource()) and have them do nothing for ELF and COFF.
> I couldnt follow this, would lld::File would have this attribute ?
Yes.

> Is this not per atom ?
Each atom has a file() method which gets the file it is from and that file has the translationUnitSource() method.  Even after the atoms are merged into one big File by the Resolver, the atom's file() method still returns the original File object.


> 
>>> 
>>> 2) Add a generic dictionary method to lld::File.  The dictionary might be empty for ELF and COFF readers, but the mach-o reader would populate the dictionary with some key/value encoding for each attribute it needs (e.g. “minOS” —> “10.9”).
> I would like this, lld::File would become more flavor neutral with this. For example if you add minOS to lld::File it would not make sense for COFF/ELF.
There will be a default (do nothing) implementation for these methods in the base class File.  COFF and ELF can just ignore them.  The dictionary design is not a normal C++ pattern.  

-Nick





More information about the llvm-commits mailing list