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

On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On May 31, 2012, at 2:39 PM, Justin Holewinski wrote:
>
> > The attached patch add the ability to programmatically re-direct
> outs()/errs() to an arbitrary raw_ostream instance, maintaining the
> raw_ostream instances in a stack structure so clients can push/pop streams
> at will.  The stack is also maintained in thread-local storage, so
> different threads can re-direct individually.  This allows for two use
> cases:
> >
> > 1. Compilers can attach custom streams to outs()/errs() to intercept
> output from LLVM without needing to play with STDOUT/STDERR.
> > 2. Compilers can receive LLVM output from different threads
> individually, instead of having all diagnostics dumped to a single stream.
>
> This isn't the right approach.  Nothing in the library part of the
> compiler should be hard coding a stream to write to.  What are you trying
> to accomplish?
>
There are a lot of places where warning/debug information is passed
directly to errs().  For example, take the Linker class.  You can tell it
to omit errors/warnings, but it would be preferable to let it emit the
errors/warnings to some compiler-controlled stream for message triaging.

For compilers that are (a) multi-threaded, or (b) invoked as part of an
embedded library, writing any information from the core libraries directly
to stderr is bad.  I want to be able to capture this output without messing
with the process' stdout/stderr streams.

This patch essentially prevents LLVM library code from having to hard-code
streams for error/warning/diagnostic output.  Library code can just use
outs()/errs() as they do now, but the compiler process/thread now has the
ability to re-direct this output as it sees fit. If no such functionality
is needed, the default behavior is to write to stdout/stderr as it does now.

>
> -Chris
>
> _______________________________________________
> 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-dev/attachments/20120531/5206dc1b/attachment.html>

On Thu, May 31, 2012 at 10:21 PM, Justin Holewinski <
justin.holewinski at gmail.com> wrote:
> On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at
apple.com> wrote:
>
>>
>> On May 31, 2012, at 2:39 PM, Justin Holewinski wrote:
>>
>> > The attached patch add the ability to programmatically re-direct
>> outs()/errs() to an arbitrary raw_ostream instance, maintaining the
>> raw_ostream instances in a stack structure so clients can push/pop
streams
>> at will.  The stack is also maintained in thread-local storage, so
>> different threads can re-direct individually.  This allows for two use
>> cases:
>> >
>> > 1. Compilers can attach custom streams to outs()/errs() to
intercept
>> output from LLVM without needing to play with STDOUT/STDERR.
>> > 2. Compilers can receive LLVM output from different threads
>> individually, instead of having all diagnostics dumped to a single
stream.
>>
>> This isn't the right approach.  Nothing in the library part of the
>> compiler should be hard coding a stream to write to.  What are you
trying
>> to accomplish?
>>
>
> There are a lot of places where warning/debug information is passed
> directly to errs().  For example, take the Linker class.  You can tell it
> to omit errors/warnings, but it would be preferable to let it emit the
> errors/warnings to some compiler-controlled stream for message triaging.
>
> For compilers that are (a) multi-threaded, or (b) invoked as part of an
> embedded library, writing any information from the core libraries directly
> to stderr is bad.  I want to be able to capture this output without messing
> with the process' stdout/stderr streams.
>
> This patch essentially prevents LLVM library code from having to hard-code
> streams for error/warning/diagnostic output.  Library code can just use
> outs()/errs() as they do now, but the compiler process/thread now has the
> ability to re-direct this output as it sees fit. If no such functionality
> is needed, the default behavior is to write to stdout/stderr as it does
now.
>
Perhaps I'm just getting the wrong impression from the current LLVM code
base.  Take this snippet from LinkModules.cpp:

  if (!SrcM->getDataLayout().empty() &&
!DstM->getDataLayout().empty() &&
      SrcM->getDataLayout() != DstM->getDataLayout())
    errs() << "WARNING: Linking two modules of different data
layouts!\n";
  if (!SrcM->getTargetTriple().empty() &&
      DstM->getTargetTriple() != SrcM->getTargetTriple()) {
    errs() << "WARNING: Linking two modules of different target
triples: ";
    if (!SrcM->getModuleIdentifier().empty())
      errs() << SrcM->getModuleIdentifier() << ": ";
    errs() << "'" << SrcM->getTargetTriple()
<< "' and '"
           << DstM->getTargetTriple() << "'\n";
  }

Would I be correct in assuming that this is actually "bad" code since
it's
a library function that writes directly to stderr?

Is the recommended approach to pass a stream to the constructor of any pass
or function that wants to emit output outside of debug mode?  My concern
with this approach is that the compiler would then need to know which
passes expect an output stream, and which do not.  The supplied patch
allows passes to output information without having to worry about where the
output is going, it is up to the compiler to specify where this output
goes.

>
>
>>
>> -Chris
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
>
> --
>
> Thanks,
>
> Justin Holewinski
>
>

-- 

Thanks,

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

On Jun 1, 2012, at 3:48 PM, Justin Holewinski wrote:
> This isn't the right approach.  Nothing in the library part of the
compiler should be hard coding a stream to write to.  What are you trying to
accomplish?
> 
> There are a lot of places where warning/debug information is passed
directly to errs().  For example, take the Linker class.  You can tell it to
omit errors/warnings, but it would be preferable to let it emit the
errors/warnings to some compiler-controlled stream for message triaging.
Yes, this is broken.  The fix should be in the linker though, not in errs().
> Perhaps I'm just getting the wrong impression from the current LLVM
code base.  Take this snippet from LinkModules.cpp:
> 
>   if (!SrcM->getDataLayout().empty() &&
!DstM->getDataLayout().empty() &&
>       SrcM->getDataLayout() != DstM->getDataLayout())
>     errs() << "WARNING: Linking two modules of different data
layouts!\n";
>   if (!SrcM->getTargetTriple().empty() &&
>       DstM->getTargetTriple() != SrcM->getTargetTriple()) {
>     errs() << "WARNING: Linking two modules of different target
triples: ";
>     if (!SrcM->getModuleIdentifier().empty())
>       errs() << SrcM->getModuleIdentifier() << ":
";
>     errs() << "'" << SrcM->getTargetTriple()
<< "' and '"
>            << DstM->getTargetTriple() <<
"'\n";
>   }
> 
> Would I be correct in assuming that this is actually "bad" code
since it's a library function that writes directly to stderr?
Yes, this is extremely unfriendly to using the linker as a library.  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).
> Is the recommended approach to pass a stream to the constructor of any pass
or function that wants to emit output outside of debug mode?  My concern with
this approach is that the compiler would then need to know which passes expect
an output stream, and which do not.  The supplied patch allows passes to output
information without having to worry about where the output is going, it is up to
the compiler to specify where this output goes.
The right fix for this is to fix the code to not report errors textually.

-Chris

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