[llvm-commits] [LLVMdev] [PATCH] Allow per-thread re-direction of outs()/errs()

[Justin Holewinski]

On Sun, Jun 3, 2012 at 4:15 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Sun, 03 Jun 2012 12:12:06 -0700
> Chris Lattner <clattner at apple.com> wrote:
>
> >
> > On Jun 2, 2012, at 11:01 AM, Mikael Lyngvig wrote:
> >
> > > If I may add my two cents:
> > >
> > > I am planning to use LLVM as the backend for a compiler I am
> > > working on.  And I wholeheartedly agree with Justin that it is a
> > > problem, if LLVM is allowed to freely write to stdout and stderr as
> > > it is a component which can be used in all sorts of code, be it a
> > > GUI IDE, a CLI driver, or whatever.
> >
> > LLVM should not be doing this.
> >
> > > Also, I have a number of times wondered about the somewhat unusual
> > > use of error strings in LLVM (that you pass in a string, which can
> > > be assigned a descriptive error message).  Better would be, IMHO,
> > > to provide an interface along the lines of this:
> > >
> > > class ErrorHandler
> > > {
> > > public:
> > >         virtual void Report(ErrorKind kind, uint code, const
> > > Position &position, const unichar *text, ...) = 0; };
> > >
> > > And then let the client, i.e. the frontend, derive from it and
> > > handle all the output in whichever way it wants to.  The above
> > > example is probably too complex for LLVM, but that's what I use in
> > > my compiler.  ErrorKind is ErrorKind_Fatal, ErrorKind_Error, etc.
> > > Position is simply a filename, a line number, and a character
> > > position.  unichar is either char or wchar_t, depending on the
> > > build mode and target environment.
> >
> > You're right, this would be better.  We have even already have it :)
> >
> >   llvm/Support/ErrorHandling.h
>
> This seems to only handle fatal errors. If that's correct, it will
> probably need to be extended to handle non-fatal errors, warnings,
> suggestions, notes, etc.
>

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)?

This leaves the following issues:

   1. 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! :)
   2. 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.

With LLVMContext::emitDiagnostic, this should cover my use case.


>  -Hal
>
> >
> > -Chris
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120603/7a8713ea/attachment.html>