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

[Justin Holewinski]

On Fri, Jun 1, 2012 at 7:08 PM, Caldarale, Charles R <
Chuck.Caldarale at unisys.com> wrote:

> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> > Subject: Re: [LLVMdev] [llvm-commits] [PATCH] Allow per-thread
> re-direction of outs()/errs()
>
> > It would be much better for the linker to return its error in a proper
> way
> > (i.e. extending llvm/Support/system_error.h like llvm/Object/Error.h
> does).
>

I like the way this works, but it seems like it's still relatively unused
in LLVM except for a few low-level classes.  Is there a plan to thread this
into the rest of LLVM, like the pass framework?  My concern is not so much
the passes that are currently using errs() to output the equivalent of "not
implemented" messages, but passes that may have legitimate reasons to
output warnings/errors, or signify an error condition.  If a compiler gets
broken IR, it's reasonable to expect some pass to fail.  In such a case, it
would be nice to get an error message and error result without having to
abort the entire OS process (llvm_unreachable is an example of something I
would like to be able to intercept and handle gracefully).  Ideally, I
would like a build of LLVM that would never result in a call to abort(),
only a result status I act on in a higher-level library.


>
> > The right fix for this is to fix the code to not report errors textually.
>
> Unfortunately, the use of outs() and (especially) errs() is rampant - a
> simple grep of the 3.1 source tree shows about 1,500 instances.  One of the
> first things we had to implement in order to make LLVM usable is something
> very similar to what Justin has proposed.  Centralizing control of the
> output in outs()/errs() would seem to be an ideal way to let users of LLVM
> as a library customize it as they see fit without requiring massive source
> changes.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/209f88fa/attachment.html>