[LLVMdev] [lld] Diagnostics

Nick Kledzik kledzik at apple.com
Mon Oct 7 19:03:58 PDT 2013


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.  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.


>  
> 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.
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131007/654243d8/attachment.html>


More information about the llvm-dev mailing list