[lld] r217324 - Remove dead code.

[Rui Ueyama]

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.

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