search for: isdebug

...t loop, it is nice to be able to tell which callbacks are "debugged" currently, either via `debug()` or `debugonce()`. Gabor > Best, > Tomas > On 04/28/2018 01:57 PM, G?bor Cs?rdi wrote: > > debugonce() sets a different flag (RSTEP), and this is not queried by > > isdebugged(), and it is also not unset by undebug(). > > > > Is this expected? If yes, is there a way to query and unset the RSTEP flag > > from R code? > > > > ? f <- function() { } > > ? debugonce(f) > > ? isdebugged(f) > > [1] FALSE > > > >...

debugonce() sets a different flag (RSTEP), and this is not queried by isdebugged(), and it is also not unset by undebug(). Is this expected? If yes, is there a way to query and unset the RSTEP flag from R code? ? f <- function() { } ? debugonce(f) ? isdebugged(f) [1] FALSE ? undebug(f) Warning message: In undebug(f) : argument is not being debugged ? f() debugging in:...

...a breakpoint in say gdb. undebugonce() would make no sense in this context, because it is done implicitly. undebugonce() would only make sense if you called debugonce() but then changed your mind before running that function, but, that does not seem like a common use case worth supporting. Re isdebugged(), I think the current semantics is already problematic. The name of the function and its existence makes it tempting to believe it tells us whether a given function is being run in a debugger currently, but it is not what isdebugged() does, the debugger can be entered by other means, includ...

...nctions set with debug() or trace()? > Best, > Phillipe, As Thomas noted, R does not currently allow testing whether a function is being debugged. However, it is possible to add this feature. I'm attaching a patch to the end of this message that adds a new internal function "isdebug" which tests if its (only) argument is a function with debugging enabled. It can be used by: > f <- function() 1 > isdebug(f) [1] FALSE > debug(f) > isdebug(f) [1] TRUE Using this, it is simple construct a function that gets a list of current objects and uses isdebug t...

This is kind of a dumb question: I know you can use isdebugged() to find out if a specific function is flagged for debugging, but is there a way to list all the functions that are flagged for debugging? Thanks, Andrew [[alternative HTML version deleted]]

Hi list, Is there a function that can let me know which functions are being debugged? I know I'm probably not doing a very good job of keeping track of things, but it does get messier when you dig into different layers of a function. I know there is "isdebugged", but it only works on one function at a time. Thanks! ...Tao [[alternative HTML version deleted]]

...e that // we are interested in. if (op) { if ((!ReturnUses && op->isUse()) || - (!ReturnDefs && op->isDef()) || + (!ReturnDefs && op->isDef() && !op->readsReg()) || (SkipDebug && op->isDebug())) advance(); } } friend class MachineRegisterInfo; @@ -907,11 +907,11 @@ public: else assert(!Op->isDebug() && "Can't have debug defs"); } } else { // If this is an operand we don't...

debug(fun) marks "fun" for debugging, it makes sure that whenever "fun" is called, the debugger is entered undebug(fun) removes this mark; it won't stop any current debugging of that function isdebugged(fun) tells whether this mark is set or not; it does not tell whether "fun" is currently running in a debugger/browser debugonce(func) adds a different mark to the function, one that makes sure the first time "fun" is called, the debugger is entered; this is the same as wh...

...tionWithTrace" # Original definition: # function() "hello" # # ## (to see the tracing code, look at body(object)) `untrace()` has the same behavior. This is inconsistent with how debug works : foo <- function() "hello" debug2 <- function(fun) debug(fun) debug2(foo) isdebugged(foo) # [1] TRUE This can be worked around by defining : trace2 <- function(fun) eval.parent(substitute(trace(fun, quote(print("!!!"))) but I believe the current behavior is undesired and it'd be better to make it behave as `debug()`, or to throw an error. Best, Antoine [[...

Hi Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >

...## (to see the tracing code, look at body(object)) >> >> `untrace()` has the same behavior. >> >> This is inconsistent with how debug works : >> >> foo <- function() "hello" >> debug2 <- function(fun) debug(fun) >> debug2(foo) >> isdebugged(foo) >> # [1] TRUE >> >> This can be worked around by defining : >> >> trace2 <- function(fun) eval.parent(substitute(trace(fun, >> quote(print("!!!"))) >> >> but I believe the current behavior is undesired and it'd be better to ma...

...the use of the register before the '=', unless it's implicit. - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by the instruction description. (I believe that's true in all cases, but I'm not 100% sure). - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like 'implicit', 'undef', 'kill', 'dead' are used before the register e.g. 'undef %rax', 'implicit-def kill %eflags'. I don't have a syntax for the SubReg_TargetFlags at the moment. Alex > > - .... > > .......

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;

...;, >> unless it's implicit. >> - TiedTo and IsEarlyClobber aren't not serialized, as they are defined by >> the instruction description. (I believe that's true in all cases, but I'm >> not 100% sure). >> - IsUndef, IsImp, IsKill, IsDead, IsInternalRead, IsDebug - keywords like >> 'implicit', 'undef', 'kill', 'dead' are used before the register e.g. >> 'undef %rax', 'implicit-def kill %eflags'. >> I don't have a syntax for the SubReg_TargetFlags at the moment. > > Since the instru...

...odbg_begin(0), re = MRI->use_nodbg_end(); ri != re; ++ri) { MachineInstr *UseMI = &*ri; UseMI->dump (); } } ***** But I see that UseMI is DBG_VALUE %noreg, 0, !"foobar"; line no:511 inlined @[ foo.cc:364:5 ] Also, when I want to check what "isDebugValue" returns, I get this. (gdb) p UseMI->isDebugValue() $1 = true Isn't this a bug ? There seems to be something wrong or am I missing something ? TIA, Pranav Qualcomm Innovation Center (QuIC) is a member of the Code Aurora Forum.

...ect)) > >> > >> `untrace()` has the same behavior. > >> > >> This is inconsistent with how debug works : > >> > >> foo <- function() "hello" > >> debug2 <- function(fun) debug(fun) > >> debug2(foo) > >> isdebugged(foo) > >> # [1] TRUE > >> > >> This can be worked around by defining : > >> > >> trace2 <- function(fun) eval.parent(substitute(trace(fun, > >> quote(print("!!!"))) > >> > >> but I believe the current behavior i...

..., > SDValue Op, > unsigned IIOpNum, > const MCInstrDesc *II, > DenseMap<SDValue, unsigned> &VRBaseMap, > bool IsDebug, bool IsClone, bool IsCloned) { > //llvm::errs() << "Op = "; > //Op.dump(); > assert(Op.getValueType() != MVT::Other && > Op.getValueType() != MVT::Glue && > "Chain and glue operands should occur at end of operand list!&quo...

...SDValue Op, >> unsigned IIOpNum, >> const MCInstrDesc *II, >> DenseMap<SDValue, unsigned> &VRBaseMap, >> bool IsDebug, bool IsClone, bool >> IsCloned) { >> //llvm::errs() << "Op = "; >> //Op.dump(); >> assert(Op.getValueType() != MVT::Other && >> Op.getValueType() != MVT::Glue && >> "Chain and glue operands should occu...

...SDValue Op, >> unsigned IIOpNum, >> const MCInstrDesc *II, >> DenseMap<SDValue, unsigned> &VRBaseMap, >> bool IsDebug, bool IsClone, bool IsCloned) { >> //llvm::errs() << "Op = "; >> //Op.dump(); >> assert(Op.getValueType() != MVT::Other && >> Op.getValueType() != MVT::Glue && >> "Chain and glue operands should occur at end...

> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm trying to do something like this: > > // Dst = NewVReg's reg class > // *II = MCInstrDesc > // IIOpNum = II Operand Num > > if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC) > MRI->setRegClass(VReg, DstRC); >