<div class="gmail_quote">On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sun, 03 Jun 2012 12:12:06 -0700<br>
Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
<br>
><br>
> On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote:<br>
><br>
> > If I may add my two cents:<br>
> ><br>
> > I am planning to use LLVM as the backend for a compiler I am<br>
> > working on. And I wholeheartedly agree with Justin that it is a<br>
> > problem, if LLVM is allowed to freely write to stdout and stderr as<br>
> > it is a component which can be used in all sorts of code, be it a<br>
> > GUI IDE, a CLI driver, or whatever.<br>
><br>
> LLVM should not be doing this.<br>
><br>
> > Also, I have a number of times wondered about the somewhat unusual<br>
> > use of error strings in LLVM (that you pass in a string, which can<br>
> > be assigned a descriptive error message). Better would be, IMHO,<br>
> > to provide an interface along the lines of this:<br>
> ><br>
> > class ErrorHandler<br>
> > {<br>
> > public:<br>
> > virtual void Report(ErrorKind kind, uint code, const<br>
> > Position &position, const unichar *text, ...) = 0; };<br>
> ><br>
> > And then let the client, i.e. the frontend, derive from it and<br>
> > handle all the output in whichever way it wants to. The above<br>
> > example is probably too complex for LLVM, but that's what I use in<br>
> > my compiler. ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc.<br>
> > Position is simply a filename, a line number, and a character<br>
> > position. unichar is either char or wchar_t, depending on the<br>
> > build mode and target environment.<br>
><br>
> You're right, this would be better. We have even already have it :)<br>
><br>
> llvm/Support/ErrorHandling.h<br>
<br>
</div></div>This seems to only handle fatal errors. If that's correct, it will<br>
probably need to be extended to handle non-fatal errors, warnings,<br>
suggestions, notes, etc.<br></blockquote><div><br></div><div>Okay, it looks like the combination of llvm/Support/ErrorHandling.h and LLVMContext::emitError solves a part of my use case. I found the CrashRecoveryContext class, which seems to allow me to intercept the report_fatal_error() calls by installing a custom handler that writes to a custom stream and then calls abort() instead of the default exit(). Alternatively, it looks like I can just spawn a thread for the LLVM work and call pthread_exit() instead of abort() in the error handler, which does not require messing with the process signal handlers. Is there any reason to prefer one over the other (thread vs. signal)?</div>
<div><br></div><div>This leaves the following issues:</div><div><ol><li>Why is the error handling stuff in LLVMContext tied to inline asm? The error handler setter is even called setInlineAsmDiagnosticHandler. Can we make this more generic? I glossed right over the emitError methods the last time I read through this stuff because I saw "InlineAsm" everywhere and figured it wasn't the right tool for the job! :)</li>
<li>As Hal points out, this only covers errors at the moment. Is there any resistance to changing emitError to emitDiagnostic and having a SourceMgr::DiagKind argument? This should cover the case where a pass wants to emit a warning or info message that is not part to DEBUG.</li>
</ol></div><div>With LLVMContext::emitDiagnostic, this should cover my use case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Hal<br>
</font></span><div class="im HOEnZb"><br>
><br>
> -Chris<br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
<br>
<br>
--<br>
</div><div class="im HOEnZb">Hal Finkel<br>
Postdoctoral Appointee<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>