[lld] r217324 - Remove dead code.

[Nick Kledzik]

On Sep 8, 2014, at 4:34 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> Hi Nick,
> 
> I thought translationUnitSource was pointing to the line table information for the Atom ? 
That is where the reader would get the information from.

> 
> The gnu linker produces an error message by looking at the line table information when there is a undefined symbol.
That could be another use for translationUnitSource().

-Nick

> 
> On 9/8/2014 4:47 PM, Rui Ueyama wrote:
>> 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.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140908/bd34fd46/attachment.html>