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

[Justin Holewinski]

On Fri, Jun 1, 2012 at 7:30 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jun 1, 2012, at 7:08 PM, Caldarale, Charles R 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).
> >
> >> 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.
>
> Virtually all of those are in DEBUG statements or in llvm/tools.  Neither
> are relevant to the discussion.
>

In a way, they are.  What if I want a debug trace in a multi-threaded
context?  Right now, all threads would just spew to the same stream and the
result would be unreadable.  If you allow threads to setup their own outs()
and errs() streams (transparently to the rest of LLVM), you can intercept
these as you see fit, perhaps dumping each to a separate file.  I
acknowledge that you could also enforce single-threaded execution for debug
runs, but what if you are in the context of a library with no valid
stdout/stderr buffers?


>
> -Chris
>



-- 

Thanks,

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