[lld] r217324 - Remove dead code.

[Shankar Easwaran]

Hi Nick,

I thought translationUnitSource was pointing to the line table 
information for the Atom ?

The gnu linker produces an error message by looking at the line table 
information when there is a undefined symbol.

Shankar Easwaran

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