search for: livedebugvalues

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more l...

Here is LLVM IR code: https://gist.github.com/andrewrk/041af662b3ff515cd0be64ab85c112d7 That produces the following valgrind message: $ valgrind llc -filetype=obj bug.ll ==27195== Conditional jump or move depends on uninitialised value(s) ==27195== at 0x56A0917: (anonymous namespace)::LiveDebugValues::transferDebugValue(llvm::MachineInstr const&, (anonymous namespace)::LiveDebugValues::OpenRangesSet&, llvm::UniqueVector<(anonymous namespace)::LiveDebugValues::VarLoc>&) [clone .isra.207] (in /nix/store/06dpmfn74zrmman8nq8p96dg50lwbxhg-llvm-3.9.0-lib/lib/ libLLVM-3.9.so) ==27195...

...ntly not handle this case. The propagation will not be done for BB#1 because one of its predecessor BB3# doesn't have a DEBUG_VALUE %R5. But R5 is still guaranteed to correspond to argc. > > I am investigating how to extend LiveDebugValue for a case like this. That sounds like a bug in LiveDebugValues, or there must be something missing from your example. LiveDebugValues should propagate the DBG_VALUE in this case. Are you sure that R5 isn’t clobbered or regmask’ed by any instruction, and that there is no conflicting DBG_VALUE? -- adrian > > > On Wed, May 11, 2016 at 5:53 PM, Adrian...

...ables does wouldn't be necessary any more and so computing equivalence wouldn't be necessary either. > > How then do we translate this new kind of machine location into > > DWARF/CodeView variable locations, which need to know which register > > to look in? The answer is: LiveDebugValues [3]. We already perform a > > dataflow analysis in LiveDebugValues of where values "go" after > > they're defined: we can use that to take "defining instructions" and > > determine register / stack locations. We would need to track values > > from the...

Adrian, I am currently investigating issues where variables that one would expect to be available in a debugger are not in code that is compiled at optimisations other than -O0 The main problem appears to be with the LiveDebugValues::join() method because it does not allow variables to be propagated into blocks unless all predecessor blocks have an Outgoing Location for that variable. As a simple example in the C code: int func2( int); void func(int a) { int b = func2(10); for(int i = 1; i < a; i++) {...

...W_AT_location (0x00000000: [0x0000000000400480, 0x0000000000400487): DW_OP_reg5 RDI [0x0000000000400487, 0x00000000004004a3): DW_OP_reg6 RBP) Stepping through the function, we stop on the call to 'ext', and can set the value of 'bar', but because there are two locations (and LiveDebugValues picked the long term register $ebp rather than $edi), you can set "bar" but it has no effect on the call to 'ext'. AFAIUI, this is never a problem at -O0 because there's only ever one location for a variable. With optimisations, and without a way to describe multiple location...

The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win! thanks, Adrian > On May 11, 2016, at 2:52 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > In retrospect I totally agree with you. I am looking at LiveDebugValue again to see

Hi Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, >

...G_VALUE signifies is a position in the instruction stream, which could be performed in some other way (i.e., more metadata) in the future. How then do we translate this new kind of machine location into DWARF/CodeView variable locations, which need to know which register to look in? The answer is: LiveDebugValues [3]. We already perform a dataflow analysis in LiveDebugValues of where values "go" after they're defined: we can use that to take "defining instructions" and determine register / stack locations. We would need to track values from the defining instruction up to the DBG_VALU...

...relies on the call-site info provided, and the more DW_AT_call_value generated, the more debug location inputs using DW_OP_entry_value will be turned into real values. Current implementation in LLVM Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified parameters during the LiveDebugValues pass, for the places where the Code Generation truncated live range of the parameters. The potential of the functionality goes beyond this, and it means we should be able to use the entry values even for modified parameters iff the modification could be expressed in terms of its entry value. In add...

...ng -O3 result. Any thoughts or insights are appreciated. Below is a sorted list of the flags missing from each for completeness. not contained in 1pass O3 (count=18) -aa-scalar-evolution -always-inline -callsite-splitting -inject-tli-mappings -ipsccp -jump-threading-correlated-propagation -livedebugvalues -loops-loop-simplify -memdep-lazy-branch-prob -openmpopt -opt-remark-emitter-instcombine -regallocfast -speculative-execution -stackmap-liveness -tbaa-scoped-noalias -vector-combine -verify -write-bitcode not contained in multi O3 (count=67) -attributor -block-freq-loop-simplify -bra...

...t; >> not contained in 1pass O3 (count=18) >> >> -aa-scalar-evolution >> >> -always-inline >> >> -callsite-splitting >> >> -inject-tli-mappings >> >> -ipsccp >> >> -jump-threading-correlated-propagation >> >> -livedebugvalues >> >> -loops-loop-simplify >> >> -memdep-lazy-branch-prob >> >> -openmpopt >> >> -opt-remark-emitter-instcombine >> >> -regallocfast >> >> -speculative-execution >> >> -stackmap-liveness >> >> -tbaa-scop...

...vided, and the > more DW_AT_call_value generated, the more debug location inputs using > DW_OP_entry_value will be turned into real values. > > Current implementation in LLVM > > Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified > parameters during the LiveDebugValues pass, for the places where the Code > Generation truncated live range of the parameters. The potential of the > functionality goes beyond this, and it means we should be able to use the entry > values even for modified parameters iff the modification could be expressed in > terms of its...

(Remembering to +llvm-dev this time…) There has been some progress in the direction of improving debuggability of optimized code, in the past year. There have been a number of patches to improve tracking of debug info in various passes, and some more general improvements such as work on the LiveDebugValues pass. I don't think anyone has done a specific analysis to identify passes that lose debug info. However, various people/teams have an interest in making improvements here, and continue to devote some resources to the longer term project. For example there is the Extend Lifetimes work describ...

Hello all, I've found an old post (November 2016) http://lists.llvm.org/pipermail/llvm-dev/2016-November/107006.html which discussed debug information for optimized code. At the end of that discussion, Adrian broached the interest in making -O1 only enable optimizations. I see in the code ( *clang/lib/Frontend/CompilerInvocation.cpp*, in function *getOptimizationLevel*) that *-Og* option is

...is time…) > > > > There has been some progress in the direction of improving debuggability > of optimized code, in the past year. There have been a number of patches > to improve tracking of debug info in various passes, and some more general > improvements such as work on the LiveDebugValues pass. I don't think > anyone has done a specific analysis to identify passes that lose debug info. > > However, various people/teams have an interest in making improvements > here, and continue to devote some resources to the longer term project. > For example there is the Exten...

> On May 11, 2016, at 2:09 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Good point. > > Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x" > > My fix would be to propagate the DEBUG_VALUE only if "x" is associated with only a

...outs more optimisation passes and installs bugfixes. (Commits there are not written to be human consumable, alas). There are no fatal flaws in the design as far as I'm aware, although there are some annoyances (see "Limitations"). The biggest problem is that this all relies on a new LiveDebugValues implementation that doesn't have sufficient test coverage yet, and is still Somewhat Experimental (TM). Given the number of times an unpleasant performance cliff has been found in VarLoc LiveDebugValues, it wants a long time to soak in before being deployed. Limitations =========== Here's...

I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct

...llvm-dev this time…) > > > > There has been some progress in the direction of improving debuggability of optimized code, in the past year. There have been a number of patches to improve tracking of debug info in various passes, and some more general improvements such as work on the LiveDebugValues pass. I don't think anyone has done a specific analysis to identify passes that lose debug info. > > However, various people/teams have an interest in making improvements here, and continue to devote some resources to the longer term project. For example there is the Extend Lifetimes w...