search for: debugflag

...up? > > > > Next iteration. > > Will this setup a signal handler in a Release+Asserts build? > That is not very nice, a library shouldn't setup signal handlers, except > in debug mode. Here's a revision. It only adds the handler if DisableDebugBuffering is false, DebugFlag is true and the debug buffer size is non-zero. -Dave Index: include/llvm/Support/Debug.h =================================================================== --- include/llvm/Support/Debug.h (revision 91825) +++ include/llvm/Support/Debug.h (working copy) @@ -28,6...

So, I've long known and it makes sense that when you're booted from a ZFS volume, you can't mess with the boot-loader. And, I know a few months ago I had a set of commands I would use when booted from a CD that would initialize the network and copy the "release/boot" from somewhere else so that I could install bootblocks and boot-loaders from more recent code. Sadly, I

I often use a debug flag (set to TRUE) to turn on various debugging print statements in my R scripts.  I was thinking I should create a function debugPrint(object,debugFlag), to print out the object name and contents if the debugFlag is set to TRUE.  Then I wouldn't have to make my script ugly(..er) than it already is by adding IF statements all over the place.  I've seen how ls() dumps object names, but how do I get access to the character representation of t...

...a great guide!), and it went all smoothly, except: option -free-form no longer was passed to g77 (from Rtools), which caused compilation to fail. Renaming Makevars to Makevars.win did not help. Investigating this in more detail, I found that MakeDLL contains the line <snip> FFLAGS=-O2 $(DEBUGFLAG) <snip> so PKG_FFLAGS weren't used at all. Changing this line to <snip> FFLAGS=$(PKG_FFLAGS) -O2 $(DEBUGFLAG) <snip> resolved the problem, however. I subsequently was again able to access the routines of the built library. My question now is: is this behaviour intended, and,...

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

...ude "llvm/Support/circular_raw_ostream.h" +#include "llvm/System/Signals.h" + using namespace llvm; // All Debug.h functionality is a no-op in NDEBUG mode. @@ -37,6 +40,16 @@ Debug("debug", cl::desc("Enable debug output"), cl::Hidden, cl::location(DebugFlag)); +// -debug-buffer-size - Buffer the last N characters of debug output +//until program termination. +static cl::opt<unsigned> +DebugBufferSize("debug-buffer-size", + cl::desc("Buffer the last N characters of debug output" + &quot...

...faces keep changing, so simply upgrading to the latest release isn't possible. Even the tiny test case I posted doesn't work with the latest version: there were changes needed to get it to compile. Also, I can no longer figure out how to turn on debugging dumps in the JIT. The simple DebugFlag = true; CurrentDebugType = "x86-emitter"; no longer works, and there seems to be no replacement for it. Andrew.

Hi Eric and thanks for your answer, What I mean is that I want to find the number of line on the IR code of a specific instruction. I found out that I can use: DebugLoc Loc = CurrentInstruction->getDebugLoc(); unsigned Line = Loc.getLine(); But this works only if DEBUGFLAG is True. I'd like to be able to get the Line number without being on a 'Debug' mode. Is this possible? Thanks again, -irini On 15/12/2015 09:37, Eric Christopher wrote: > Not sure what you mean, but the answer is likely "no" as there's > nothing for anything to...

...t;i32*> [#uses=3] store i32 20, i32* %b, align 4 call void @add1(i32* %b) nounwind %0 = load i32* %b, align 4 ; <i32> [#uses=1] %1 = add nsw i32 %0, 10 ; <i32> [#uses=1] ret i32 %1 } declare void @add1(i32*) *** When using llvm::DebugFlag=true JIT gives me following debug messages: ********** Function: main Ifcvt: function (0) 'main' block 0 offset 0 size 40 block 0 offset 0 size 40 JITTing function 'main' JIT: Starting CodeGen of Function main JIT: Emitting BB0 at [0x4512e010] JIT: 0x4512e010: STM %SP, 12, 14, %re...

...eration. >> >> Will this setup a signal handler in a Release+Asserts build? >> That is not very nice, a library shouldn't setup signal handlers, except >> in debug mode. > > Here's a revision. It only adds the handler if DisableDebugBuffering is > false, DebugFlag is true and the debug buffer size is non-zero. Please reverse the sense of this, forcing clients to opt into dbgs() buffering, and update the tools to set the flag. Looks good otherwise, -Chris

the other day i was trying to create a new freebsd slice on the same disk i booted from (on a freshly updated RELENG_6) and both fdisk and sysinstall failed with some error (i think they could not write on the disk, or something similar). boot -s did not seem to help, either. I remember vaguely some time ago a bit of discussion on this topic, but cannot recall the outcome nor any keyword to

...ly > upgrading to the latest release isn't possible. Even the tiny > test case I posted doesn't work with the latest version: there > were changes needed to get it to compile. Also, I can no longer > figure out how to turn on debugging dumps in the JIT. The simple > > DebugFlag = true; > CurrentDebugType = "x86-emitter"; > > no longer works, and there seems to be no replacement for it. That should work fine, just use "jit" instead of "x86-emitter" as the debug type. -Chris

...s=packet,update,nosetdrv default_selection=F1 (Slice 1) OK, try to switch to slice 2: hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Known one, set debug flags and try again: hd30# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 hd30# boot0cfg -s 2 -v /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Er ... well, what now? Out of curiosity I tried: hd30# boot0cfg -s 2 -v /dev/ad4 # flag start chs type...

...se-1 ? SectSize : Symbols[si + 1].first - 1; + uint64_t End = si == se-1 ? SectionVMA + SectSize : Symbols[si + 1].first - 1; This goes over 80 col. outs() << '\n' << Symbols[si].second << ":\n"; #ifndef NDEBUG raw_ostream &DebugOut = DebugFlag ? dbgs() : nulls(); #else @@ -244,22 +247,22 @@ static void DisassembleObject(const ObjectFile *Obj) { #endif for (Index = Start; Index < End; Index += Size) { MCInst Inst; - if (DisAsm->getInstruction(Inst, Size, memoryObject, Index, + outs() << format...

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

...ude "llvm/Support/circular_raw_ostream.h" +#include "llvm/System/Signals.h" + using namespace llvm; // All Debug.h functionality is a no-op in NDEBUG mode. @@ -37,6 +40,15 @@ Debug("debug", cl::desc("Enable debug output"), cl::Hidden, cl::location(DebugFlag)); +// -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", + llvm::cl::desc("Save last N...

...lid log strings are used for two separate cases: > 1) The first case is for detailed debugging, which is controlled by the macro DEBUG(dbgs() << MESSAGE). In such a case, string operations will automatically skipped in normal execution mode with the following if-statement: > if (::llvm::DebugFlag && ::llvm::isCurrentDebugType(TYPE)) > That means string operations controlled by DEBUG will not execute in normal case, so we should not worry about it. > 2) The other case is for the variable "LastFailure", which is used only in GraphPrinter. Currently string operations fo...

...lvm; Module *makeLLVMModule (); Function *foo; int main (int argc, char **argv) { Module *Mod = makeLLVMModule (); verifyModule (*Mod, PrintMessageAction); PassManager PM; PM.add (new PrintModulePass ()); PM.run (*Mod); ExecutionEngine *engine = ExecutionEngine ::create(Mod); // DebugFlag = true; // CurrentDebugType = "x86-emitter"; typedef int (*pf)(); pf F = (pf)engine->getPointerToFunction(foo); int res = F(); printf ("ret = %d\n", res); delete Mod; return 0; } int32_t p = 99; Module * makeLLVMModule () { // Module Construction Module...

...strings are used for two separate cases: >> 1) The first case is for detailed debugging, which is controlled by the macro DEBUG(dbgs() << MESSAGE). In such a case, string operations will automatically skipped in normal execution mode with the following if-statement: >> if (::llvm::DebugFlag && ::llvm::isCurrentDebugType(TYPE)) >> That means string operations controlled by DEBUG will not execute in normal case, so we should not worry about it. >> 2) The other case is for the variable "LastFailure", which is used only in GraphPrinter. Currently string opera...

...Those invalid log strings are used for two separate cases: 1) The first case is for detailed debugging, which is controlled by the macro DEBUG(dbgs() << MESSAGE). In such a case, string operations will automatically skipped in normal execution mode with the following if-statement: if (::llvm::DebugFlag && ::llvm::isCurrentDebugType(TYPE)) That means string operations controlled by DEBUG will not execute in normal case, so we should not worry about it. 2) The other case is for the variable "LastFailure", which is used only in GraphPrinter. Currently string operations for "L...