[lld] Diagnostics

Hi,

lld doesnot have a Diagnostics interface, It uses llvm::errs() to display errors after linking has been done.

I think the Diagnostics interface follow similiar interface patterns as followed by clang (using Diagnostic td files).

What do you think ?

Thanks

Shankar Easwaran

Ping ?

I think having diagnostics interface similar to Clang’s would be good. I think the total number of defined warnings would be much smaller than Clang.

Much like the options library, it has been a long-term desire to refactor
all of the Clang diagnostics infrastructure into a largely independent
library that could be used by lots of different tools, Clang, LLD, and even
some internal tools that would benefit from improved diagnostic interfaces.

There is already a heavy similarity between the LLVM diagnostic interfaces
and Clangs, so this might not be completely unreasonable, but it is a
really significant undertaking.

I think we need a straw man proposal to start iterating on. Clang’s diagnostics has lots of good features. But is has lots that a linker does not need. For instance, the line/column number does not make sense for a linker. Clang errors/warnings are mostly about the source language which is pretty standard across different platforms. Other than multiple-defined and undefined errors, most of the linker errors and warnings will be platform specific.

Linker warnings and errors are also historically very cryptic. Linker errors usually have a low level cause, and a high level action for the developer to take to resolve the issue. For instance, the low level trigger would be a particular relocation kind is not expected. The high level fix is to change the compiler options (e.g. -fno-pic) for a particular file. It would be nice to capture the low and high level in lld’s diagnostics.

-Nick

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.

Clang errors/warnings are mostly about the source language which is pretty
standard across different platforms. Other than multiple-defined and
undefined errors, most of the linker errors and warnings will be platform
specific.

I don't think this difference is significant. There are a enough platform
specific warnings in Clang (at-exit and destructor handling) for us to have
some need of machinery here.

I suspect that the bigger difference is the object file format differences
(ELF vs. Mach-O vs. COFF), but that seems not substantially different from
language differences (C89, C99, C++, ObjC).

Linker warnings and errors are also historically very cryptic. Linker
errors usually have a low level cause, and a high level action for the
developer to take to resolve the issue. For instance, the low level
trigger would be a particular relocation kind is not expected. The high
level fix is to change the compiler options (e.g. -fno-pic) for a
particular file. It would be nice to capture the low and high level in
lld’s diagnostics.

Very much so. We've also had some great experience using debug info (when
present) to produce much more detailed and user-friendly diagnostics in the
linker.

I think we need a straw man proposal to start iterating on. Clang’s
diagnostics has lots of good features. But is has lots that a linker does
not need. For instance, the line/column number does not make sense for a
linker.

Linker scripts will need this (although we still don't really have a good
idea of how to fully integrate the necessary subset of linker script
functionality into LLD, and it's not clear when that will become a
priority).

-- Sean Silva

I’m curious what that looks like and if it is useful in practice. I experimented with this years ago in the darwin linker. When there was an undefined symbol, the linker could (if there was debug info in the object file) print out the source and approximate line number where the call to the undefined symbol was made. This turned out to not be useful for two reasons: 1) very often an undefined symbol is used from multiple locations, so you wind up with lots of source/line spewage, 2) usually the reason for an undefined symbol is that you forgot to link with some library. Showing the user the source file that called some undefined function does not help. Showing the header that declared the function would be more helpful (since their is a better association between libraries and their headers), but which header declared a function is not in the debug info.

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.

Yes. We need diagnostics machinery. My point was more that most of the .td files defining the warnings/errors will be platform/format specific.

-Nick

Linker scripts are generally used on ELF, and the current ELF writer has support for it in its design (See DefaultELFLayout).

Thanks for bringing up the diagnostics with Linker scripts as clang style diagnostics would become more useful.

Thanks

Shankar Easwaran

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 :slight_smile:

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

Are there any documents that cover the porting/usage of the diagnostic td file across other llvm tools.

This might be useful.

Thanks

Shankar Easwaran