<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 7:02 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div>
</div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.  </div>
<div><br></div><div>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.  </div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nick</div></font></span><div><div class="h5"><div><br></div><br><div><div>On Oct 7, 2013, at 3:36 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div>
<blockquote type="cite"><div dir="ltr">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.<br><div class="gmail_extra">
<br><div class="gmail_quote">

On Mon, Oct 7, 2013 at 3:19 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Ping ?<div><div><br>
<br>
On 10/4/2013 10:41 PM, Shankar Easwaran wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
lld doesnot have a Diagnostics interface, It uses llvm::errs() to display errors after linking has been done.<br>
<br>
I think the Diagnostics interface follow similiar interface patterns as followed by clang (using Diagnostic td files).<br>
<br>
What do you think ?<br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
</blockquote>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>