similar to: [LLVMdev] debug macros

On Monday 21 December 2009 10:14, Török Edwin wrote: > 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. >

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. > > Why don't you just check #ifndef NDEBUG like the code that sets it up?

Michael, I have not made any changes since I last posted a patch. If you would like to make the final updates, thats fine by me. I don't mind making the changes either, I can have them done this evening as well. Chris, As far as naming goes, PE/COFF used in Microsoft's document because they are describing both their version of COFF, and their Portable Execution format which is a

Nathan, do you have any other changes? If not, I can make these changes and have a patch ready this evening. Sent from my iPhone On Jun 14, 2010, at 2:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 11, 2010, at 6:44 PM, Michael Spencer wrote: > >> Here is a full patch including Nathan's COFF support, tests that pass >> on Windows, and some

On Jun 11, 2010, at 6:44 PM, Michael Spencer wrote: > 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 Hi Guys, What is the status of this patch? Here are some comments on

On Jun 14, 2010, at 12:41 PM, Nathan Jeffords wrote: > Michael, > > I have not made any changes since I last posted a patch. If you would like to make the final updates, thats fine by me. I don't mind making the changes either, I can have them done this evening as well. > > Chris, > > As far as naming goes, PE/COFF used in Microsoft's document because they are

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 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", > > +

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

Moving this discussion here from the review thread. RIght now, we have a few passes that prefix DEBUG message with various things, so folks using -debug can tell where the debug message came from. But this is not consistent, and in fact, most passes don't do it. Worse, the prefixes used do not often match the DEBUG_TYPE of the pass. It would be nice to fix this, and just have the DEBUG

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

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

----- Original Message ----- > From: "Matthias Braun via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, November 2, 2015 1:16:18 PM > Subject: Re: [llvm-dev] Prefixing DEBUG messages with DEBUG_TYPE (was re: [PATCH] D13259: LLE 6/6: Add

On 2 May 2010 10:53, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, Nathan > I'll let others comment on MC hooks, I just made a very brief look > over the contents of the archive. You can find the comments below. > Yes I looked at this and there are several ways but TargetAsmBackend looked the bast place to deal with the MCStreamer choice for different

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:

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 want to buffer ALL output so that you don't get some

Hi All, I have created a minimally functional Win32 COFF Exporter using the new MC framework. I made some minor changes to other libraries to allow me to plug it in without building it as part of the LLVM project. I wanted to share it but wasn't sure how to go about doing so, so I have attached the code to this message. Any feedback on would be appreciated. -------------- next part

On Thu, Sep 23, 2010 at 4:04 AM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Thu, Sep 23, 2010 at 2:40 AM, Nathan Jeffords > <blunted2night at gmail.com> wrote: > > here are a couple of patches to address some warnings > > in Microsoft compilers, and a build error in vs2010 in particular > > vs2010-errors.patch: > > In SelectionDAGISel,

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

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