search for: dbgs

Here's an example patch of how dbgs() will be used. Essentially I will replace uses of errs() with dbgs(). I believe this is the correct thing to do because: - With #define NDEBUG, dbgs() == errs() - With debugging and -debug-buffer-size=0 (the default), dbgs() just passes output to errs(). - When -debug-buffer-size>0, you...

...vm { +class raw_ostream; + /// DEBUG_TYPE macro - Files can specify a DEBUG_TYPE as a string, which causes /// all of their DEBUG statements to be activatable with -debug-only=thatstring. #ifndef DEBUG_TYPE @@ -72,15 +74,20 @@ #define DEBUG_WITH_TYPE(TYPE, X) do { } while (0) #endif +/// dbgs() - This returns a reference to a raw_ostream for debugging +/// messages. If debugging is disabled it returns errs(). Use it +/// like: dbgs() << "foo" << "bar"; +raw_ostream &dbgs(); + // DEBUG macro - This macro should be used by passes to emit debug infor...

...debug build, then the code specified as the option to the macro /// will be executed. Otherwise it will not be. Example: /// -/// DEBUG_WITH_TYPE("bitset", errs() << "Bitset contains: " << Bitset << "\n"); +/// DEBUG_WITH_TYPE("bitset", dbgs() << "Bitset contains: " << Bitset << "\n"); /// /// This will emit the debug information if -debug is present, and -debug-only /// is not specified, or is specified as "bitset". @@ -72,15 +74,28 @@ #define DEBUG_WITH_TYPE(TYPE, X) do { } while...

...probably also be cl::Hidden. Ok. > > +// Signal handlers - dump debug output on termination. > > +static void debug_user_sig_handler(void *Cookie) > > +{ > > + llvm::circular_raw_ostream *logout = > > + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); > > Please do not use dynamic_cast, we're trying to eliminate the last > RTTI use in the compiler. Do you want me to use dyn_cast? That means I'll have to add some more stuff to raw_ostream and circular_raw_ostream. Or I think I can just assume (Yikes!) that if the signal ha...

...David Greene wrote: >>> +// Signal handlers - dump debug output on termination. >>> +static void debug_user_sig_handler(void *Cookie) >>> +{ >>> + llvm::circular_raw_ostream *logout = >>> + dynamic_cast<llvm::circular_raw_ostream *>(&llvm::dbgs()); >> >> Please do not use dynamic_cast, we're trying to eliminate the last >> RTTI use in the compiler. > > Do you want me to use dyn_cast? That means I'll have to add some more > stuff to raw_ostream and circular_raw_ostream. No, dyn_cast is only really sui...

Here's the patch to provide dbgs(). By default it works just like errs(). When -debug-buffer-size=N (N > 0) is set, it buffers output sent to it and dumps it at program termination via a signal handler. Please review. Thanks! -Dave Index: include/llvm/Support/Debug.h ======================...

On 2009-12-21 18:06, David Greene wrote: > On Saturday 19 December 2009 00:16, Chris Lattner wrote: > > >>> Or I think I can just assume (Yikes!) that if the signal handler is >>> invoked it will really be a circular_raw_ostream since the handler >>> should (!) only be set up in debug mode. >>> >>> That scares me a bit, though. >>>

On Thursday 10 December 2009 17:53, Chris Lattner wrote: > > So I would write the above as: > > > > DEBUG(dbgs() << foo); > > > > Does that sound reasonable? > > If you're asking if a new dbgs() might be useful, "yes if specified well". > If you're asking if you can convert everything to using it, "no". I'm not sure what you mean here. It's n...

On Friday 11 December 2009 11:35, Chris Lattner wrote: = > > I'm not sure what you mean here. It's not ok to convert code under > > DEBUG() or #ifndef NDEBUG to use dbgs()? > > Right. > > > Then what's the point of providing it? > > I don't know what dbgs does, so I don't know! dbgs() will be a circular-buffering raw_ostream, meaning it saves the last N bytes (N == unlimited by default) and displays the output at program terminatio...

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

On Dec 11, 2009, at 9:03 AM, David Greene wrote: >> >> If you're asking if a new dbgs() might be useful, "yes if specified well". >> If you're asking if you can convert everything to using it, "no". > > I'm not sure what you mean here. It's not ok to convert code under DEBUG() or > #ifndef NDEBUG to use dbgs()? Right. > Then wha...

On Dec 17, 2009, at 4:02 PM, David Greene wrote: > Here's the patch to provide dbgs(). By default it works just like > errs(). > When -debug-buffer-size=N (N > 0) is set, it buffers output sent to > it and > dumps it at program termination via a signal handler. > > Please review. Thanks! > > -Dave > > Index: i...

...bug.h" > #include "llvm/Support/raw_ostream.h" > > I'm working on release 3.1 though. > > hth, Daniel > > On 11/26/2012 03:00 PM, Bjorn De Sutter wrote: >> Hi, >> >> I am trying to debug my backend, and observe very strange behavior with dbgs(): >> >> In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. >> >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, >> unsigned Cycle, unsign...

Hi, I am trying to debug my backend, and observe very strange behavior with dbgs(): In the IfConverter, I have added two debugging lines that print floating-point numbers for the sake of demonstration that such printing works fine. bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, unsigned Cycle, unsigned Extra, const...

...aw_ostream.h" > > > > I'm working on release 3.1 though. > > > > hth, Daniel > > > > On 11/26/2012 03:00 PM, Bjorn De Sutter wrote: > >> Hi, > >> > >> I am trying to debug my backend, and observe very strange behavior with > dbgs(): > >> > >> In the IfConverter, I have added two debugging lines that print > floating-point numbers for the sake of demonstration that such printing > works fine. > >> > >> bool MeetIfcvtSizeLimit(MachineBasicBlock &BB, > >>...

On Dec 11, 2009, at 9:44 AM, David Greene wrote: > On Friday 11 December 2009 11:35, Chris Lattner wrote: > = >>> I'm not sure what you mean here. It's not ok to convert code under >>> DEBUG() or #ifndef NDEBUG to use dbgs()? >> >> Right. >> >>> Then what's the point of providing it? >> >> I don't know what dbgs does, so I don't know! > > dbgs() will be a circular-buffering raw_ostream, meaning it saves > the last N bytes (N == unlimited by default) and...

On Dec 17, 2009, at 4:08 PM, David Greene wrote: > Here's an example patch of how dbgs() will be used. Essentially I > will > replace uses of errs() with dbgs(). I believe this is the correct > thing > to do because: > > - With #define NDEBUG, dbgs() == errs() > > - With debugging and -debug-buffer-size=0 (the default), dbgs() just > passes output to...

Maybe I miss something but I think there is a problem with this code in Support/Debug.cpp when compiling in Release build (NDEBUG defined): namespace llvm { /// dbgs - Return dbgs(). raw_ostream &dbgs() { return dbgs(); } } I though it would crash with a stack overflow due to infinite recursion, but llvm-gcc is smart enough to compile it as a jmp and create an infinite loop instead otool -tv Debug.o llvm::dbgs(): 0000000000000000 pushq %rbp 0000...

When using "DEBUG( dbgs() << "whatever" );" Do I need to insert a line terminator. Like "DEBUG( dbgs() << "whatever" << std::endl );" Thanks Jeff Kunkel

...ite simple - DOUT in release mode was just /dev/null, > but the functions sending data to it were still called. errs() is no good. I would want to keep errs() printing things out immediately. I need something else that buffers until program termination. So I would write the above as: DEBUG(dbgs() << foo); Does that sound reasonable? There are some tricky cases where dump routines are used either to print error messages or to print debug information. In those cases I may have to parameterize the dump routine with the stream. -Dave