[lld] r217324 - Remove dead code.

[Nick Kledzik]

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.

-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/eb0ff9e8/attachment.html>