Justin Holewinski
2012-Jun-01 05:21 UTC
[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 > lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20120531/5206dc1b/attachment.html>
Justin Holewinski
2012-Jun-01 22:48 UTC
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
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 >> lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> > > > > -- > > Thanks, > > Justin Holewinski > >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20120601/57e9b328/attachment.html>
Chris Lattner
2012-Jun-01 23:28 UTC
[LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
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: <lists.llvm.org/pipermail/llvm-dev/attachments/20120601/4c470137/attachment.html>
Reasonably Related Threads
- [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
- [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
- [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
- [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()
- [LLVMdev] [llvm-commits] [PATCH] Allow per-thread re-direction of outs()/errs()