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

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.

-Chris

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-dev/attachments/20120601/1f140db4/attachment.html>

> From: Justin Holewinski [mailto:justin.holewinski at gmail.com] 
> Subject: Re: [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction
of outs()/errs()
> > 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?
I agree wholeheartedly.  We're running LLVM in a real-time system with no
stdout/stderr, and being able to redirect the debug messages is critical to our
testing.

 - 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.

On Jun 1, 2012, at 7:41 PM, Justin Holewinski wrote:
> >
> > 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?
> 
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.

-Chris

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