search for: debug_with_type

.../Debug.h (working copy) @@ -28,6 +28,8 @@ namespace llvm { +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...

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

...PE as a string, which causes /// all of their DEBUG statements to be activatable with -debug-only=thatstring. #ifndef DEBUG_TYPE @@ -58,7 +60,7 @@ /// this is a 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...

...ave two functions :- >> >> setVerboseOptions(StringRef) -> stores all the verbose options in a vector. >> >> hasVerboseOption(StringRef) -> returns true if the option is present >> >> Thoughts on the above ? > What do you mean by “verbose”. Is this like DEBUG_WITH_TYPE()? gnu ld has a verbose option that tells the user, whats going on in the linker from how it starts processing the command line to how symbols are being resolved. Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

...omething here, because people use it for more than just outputting messages. My thought was to just bite the bullet and make a DEBUG_MSG macro that outputs the DEBUG_TYPE, and replace the appropriate existing uses of DEBUG(dbgs() <<) with it. Something like #define DEBUG_MSG_WITH_TYPE(t, x) DEBUG_WITH_TYPE(t, dbgs() << t <<":" << x;) #define DEBUG_MSG(x) DEBUG_MSG_WITH_TYPE(DEBUG_TYPE, x) Suggestions, however, welcome! ---------- Forwarded message ---------- From: Renato Golin <renato.golin at linaro.org> Date: Fri, Oct 30, 2015 at 10:15 AM Subject: Re: [PATCH] D13...

...> LinkingContext will have two functions :- > > setVerboseOptions(StringRef) -> stores all the verbose options in a vector. > > hasVerboseOption(StringRef) -> returns true if the option is present > > Thoughts on the above ? What do you mean by “verbose”. Is this like DEBUG_WITH_TYPE()? -Nick

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L c)

On Dec 18, 2009, at 6:36 PM, 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

On Friday 18 December 2009 19:56, Chris Lattner wrote: > > +// -debug-buffer-size - This is a command line op0tion to set the > > size > > +// of the debug stream circular buffer. The value is the number of > > +// characters to save. > > +static cl::opt<unsigned> > > +DebugBufferSize("debug-buffer-size", > > +

.... +#define dbgout(x) DEBUG(dbgs() << x) +#define dbgerr(x) do { dbgout (__FILE__ << "(" << __LINE__ <<\ + ") : " << x << '\n'); llvm_unreachable("unexpected error occured");\ + } while (false) + +#define dbgout_call(x) DEBUG_WITH_TYPE(DEBUG_TYPE"_calls", dbgs() << \ + __FUNCTION__ << " (" << x << ")\n") + +#define dbg_notimpl(x) dbgerr("not imlemented, " << __FUNCTION__ \ + << " (" << x << ")"...

.../Debug.h (working copy) @@ -28,6 +28,8 @@ namespace llvm { +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...

Here is a full patch including Nathan's COFF support, tests that pass on Windows, and some changes to lit. Obviously the COFF support and changes to lit should be separate patches in the end. http://codereview.appspot.com/1624043/show - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support.patch Type: application/octet-stream Size:

...gs() << x) > +#define dbgerr(x) do { dbgout (__FILE__ << "(" << __LINE__ <<\ > + ") : " << x << '\n'); llvm_unreachable("unexpected error > occured");\ > + } while (false) > + > +#define dbgout_call(x) DEBUG_WITH_TYPE(DEBUG_TYPE"_calls", dbgs() > << \ > + __FUNCTION__ << " (" << x << ")\n") > + > +#define dbg_notimpl(x) dbgerr("not imlemented, " << __FUNCTION__ \ > + << " (" <&l...

...sages. > > > > My thought was to just bite the bullet and make a DEBUG_MSG macro > > that outputs the DEBUG_TYPE, and replace the appropriate existing > > uses of DEBUG(dbgs() <<) with it. > > > > Something like > > #define DEBUG_MSG_WITH_TYPE(t, x) DEBUG_WITH_TYPE(t, dbgs() << t > > <<":" << x;) > > #define DEBUG_MSG(x) DEBUG_MSG_WITH_TYPE(DEBUG_TYPE, x) > > > > Suggestions, however, welcome! > > > > ---------- Forwarded message ---------- > > From: Renato Golin <renato.golin at linar...

...(x) x #else #define _dbg(x) #endif The other macro is just a slight variation on the existing DEBUG macro, but for the common case of printing something out to the debug console, its simpler to write, and in my opinion easier to read. #define dbgout(x) DEBUG(dbgs()<<x) #define dbgoutc(y,x) DEBUG_WITH_TYPE(x,dbgs()<<y) -Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100512/5003077e/attachment.html>

+1, claiming the "DEBUG" macro is pretty hostile. Debug.h is included pretty widely from llvm/include/llvm/*, so we can't claim this is some internal macro that users won't see. On Fri, Mar 23, 2018 at 9:18 AM Nicola Zaghen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > We recently stumbled upon some issues with the DEBUG() macro being >

...x) >> +#define dbgerr(x) do { dbgout (__FILE__ << "(" << __LINE__ <<\ >> + ") : " << x << '\n'); llvm_unreachable("unexpected error occured");\ >> + } while (false) >> + >> +#define dbgout_call(x) DEBUG_WITH_TYPE(DEBUG_TYPE"_calls", dbgs() << \ >> + __FUNCTION__ << " (" << x << ")\n") >> + >> +#define dbg_notimpl(x) dbgerr("not imlemented, " << __FUNCTION__ \ >> + << " (&quo...

Hi all, We recently stumbled upon some issues with the DEBUG() macro being redefined in some internal libraries and some external ones, such as LLVM. After trying out a few ideas to avoid the problem we thought that the simplest solution would be to prefix all generic macro names in order to avoid clashes. A quick search showed that Mesa had a similar issue with DEBUG being used by LLVM and

...mmand to generate the VS solution is pretty uninteresting: cmake -G "Visual Studio 15 Win64" ..\llvm I fixed a few of the link errors that Jack pointed out before stumbling on the problem in AsmMatcherEmitter::run(). I wasn't comfortable attempting to work around it there because the DEBUG_WITH_TYPE macro was conflicting with trying to guard calls to MatchableInfo::dump() with LLVM_ENABLE_DUMP. I think this is another instance of "TableGen wasn't done along with the rest of llvm" -- nothing about it should be Visual Studio- or Windows-specific. ~Aaron > > thanks again......

On Sat, Oct 14, 2017 at 11:25 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Jack: > > Yes, I was just looking at that. Seems like TableGen wasn't done along with > the rest of llvm. I'll work up a complete patch shortly. This also broke the build for MSVC when doing a debug build (though no builder seems to be picking up the failure!). After