[lld] r217324 - Remove dead code.

[Rui Ueyama]

On Tue, Sep 9, 2014 at 5:46 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> 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.
>

I agree. The dictionary approach wouldn't reduce the complexity, but just
hides accessor methods behind a string -> attribute map. It would be slow,
unsafe, and hard to understand. It's not a normal C++ pattern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140909/d61ad4a0/attachment.html>