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.> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131007/496f7e2f/attachment.html>
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>
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