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

[Chris Lattner]

On Jun 1, 2012, at 11:13 PM, Justin Holewinski wrote:
>> 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?
>> 
> 
> This doesn't make any sense.  There is very little sense in trying to use DEBUG (which gets compiled out of optimized builds) in a multithreaded context.  Polluting the purity of outs() and errs() because of this sort of use case doesn't make any sense to me.
> 
> outs() and errs() are useful independent of how LLVM happens to use them.  The extensions that you are proposing doesn't make any sense give nthe design of raw_ostream.
> 
> Is the problem more that outs() and errs() should always point to valid stdout/stderr streams, regardless of how the hosting compiler is implemented?

No.  outs() and errs() are equivalent to stdout and stderr.  Your request to change how they work to be thread local is like saying that we should change how printf works because LLVM is misusing printf somewhere.

> If so, how do you feel about introducing a new global stream, logs()?  This could replace all uses of outs()/errs() in the LLVM libraries, and default to errs().  Existing command-line tools could just use this default, but compilers that are hosted inside of libraries or other non-command line scenarios can attach a custom stream to logs() that captures all LLVM output, including DEBUG and any legitimate pass output.  Command-line tools can continue to use outs()/errs() just as they do now.  Nothing would really change in the way LLVM operates by default

In fact, before we had raw_ostream, we had a dbgs() sort of stream, which was intended to be used in debug statements.  I'm not strongly opposed to this (it would be much better than violating the sanctity of outs() :), but I'm still unclear why you care so much about DEBUG output.  If we had a dbgs() again, it should *only* be used from within DEBUG macros (for example, the linker shouldn't use it).  Would that be enough to achieve your goal?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120602/0c9d0f61/attachment.html>