[LLVMdev] [lld] Diagnostics

[Shankar Easwaran]

On 10/7/2013 9:03 PM, Nick Kledzik wrote:
> On Oct 7, 2013, at 5:15 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
>> On Mon, Oct 7, 2013 at 4:02 PM, Nick Kledzik <kledzik at apple.com> wrote:
>> But is has lots that a linker does not need.  For instance, the line/column number does not make sense for a linker.
>>
>> Really? Gold has errors that mention lines and columns. It gets them by querying the debug information for file, line, and column. There may be examples of this, but I don't think source location is one of them.
> I’m curious what that looks like and if it is useful in practice.
The undefined symbol has helped me a lot when dealing with a lot of 
archive libraries. I think it saves developer time. May be the linker 
can do this when the user wants to get more verbose output from the linker ?
> As an aside, in Xcode5 we are experimenting with fixing the undefined symbol problem via “auto linking”.  When modules are enabled, the compiler annotates the object file with what libraries might be needed to link it.  The linker then builds a list of all the auto linked libraries and automatically adds ones that will resolve an undefined symbol.
How is this encoded in the object file ? Extending DWARF information ?
> Yes. We need diagnostics machinery.  My point was more that most of the .td files defining the warnings/errors will be platform/format specific.
Yes. I prefer diagnostic messages outside source code, makes it easier 
to change. I am not sure of old style catalog files which were 
translated from one language to another :)

Also in addition to this, I think core diagnostic messages would still 
include

a) Detailed stats on how much time was spent in each stage ?
b) Integrating other parts of LLVM
c) I am sure when lld has LTO, it would need more diagnostics
d) Veneers/Trampoline creation (I think the diagnostics could be general 
on where it inserted a veneer/call to the veneer)
e) Pass information
f) Reading native file format information

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation