[lld] r217324 - Remove dead code.

[Rui Ueyama]

On Mon, Sep 8, 2014 at 2:28 PM, Nick Kledzik <kledzik at apple.com> wrote:

>
> On Sep 8, 2014, at 2:19 PM, Rui Ueyama <ruiu at google.com> wrote:
>
> On Mon, Sep 8, 2014 at 2:00 PM, Nick Kledzik <kledzik at apple.com> wrote:
>
>>
>> On Sep 6, 2014, at 6:23 PM, Rui Ueyama <ruiu at google.com> wrote:
>> >
>> > -  /// \brief Returns the path of the source file used to create the
>> object
>> > -  /// file which this (File) object represents.  This information is
>> usually
>> > -  /// parsed out of the DWARF debug information. If the source file
>> cannot
>> > -  /// be ascertained, this method returns the empty string.
>> > -  virtual StringRef translationUnitSource() const;
>> > -
>> 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.
>>
>> 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”).
>>
>> 3) Push this through the atom model by having a new
>> DefinedAtom::ContentType (e.g. typeMachOMeta) and having the mach-o reader
>> produce a new typeMachOMeta atom with the atom name being the “key” and the
>> atom’s content bytes being its “value”.  You can think of this like the
>> .comment section in ELF being transformed into an Atom.  In mach-o most of
>> the extra attribute information is encoded in load commands in the file
>> header - not in sections, so there is no natural mapping to atoms.
>>
>
> I think I strongly prefer 1 over 2 or 3 as it seems simpler and more
> straightforward than the others. It would be the easiest to implement for
> you, and it wouldn't also hurt the others. No. 2 basically does the same
> thing as No. 1 but in a rather complicated manner. No 3 is a possibility
> but it really sounds like a hack.
>
> I prefer No. 1 too.  But we’ve tried to keep platform specific attributes
> out of DefinedAtom.  So, I wanted to make sure we were not keeping that
> strictness for File too.
>

I want to keep the code shared by all architectures simple and clean, but
it doesn't always mean that we can only put the least common denominator
there. For example, if we are going to support an architecture on which the
linker's functionality is really limited, should we move the existing
shared code to each port, so that we don't have now-architecture-dependent
code in Core? Probably not. The functions you want to add falls in that
category. We should choose No. 1 for the sake of simplicity (= our
productivity).


-Nick
>
>
>> [1] Debug map:
>> On darwin, the linker does not copy dwarf debug info from .o files into
>> the final executable.  Instead the linker generates a “debug map” in the
>> final executable.  This is essentially a table that maps each function to
>> its .o file and source file.  When you start debugging a program you just
>> built, the debugger sees no dwarf - just the debug map.  If you set a break
>> in file “foo.c; line 100”, the debugger will consult the debug map and see
>> which .o file(s) came from “foo.c”.  It will then open those .o files and
>> parse their dwarf debug info.  It can then combine that dwarf info with the
>> debug map info to figure out what address in memory to set the break point.
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140908/5f6cf8cb/attachment.html>