search for: dbgvaluehistorycalculator

Displaying 14 results from an estimated 14 matches for "dbgvaluehistorycalculator".

2015 Jun 23
4
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
Here is a proposal for improving DbgValueHistoryCalculator and the overall quality of debug locations. Focus: This is about lowering the DBG_VALUE machine instructions to DWARF location lists. Non-focus: This is not about (typical -O0) variables that permanently reside at a frame index and are described with dbg.declare intrinsics in the IR. These variab...
2015 Aug 12
3
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
...=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=M2Zg7H-gbv_tNUdRj7CBGjONnJqWE6I4H4MPu8YCxS8&s=7reEDqWf8_HRQoLhVbC4yfuU3vREoye6EczLjLAb_dU&e=>, where I tried to implement something similar. Looks like we're now at the point where we *do* require complicated solution and analysis in DbgValueHistoryCalculator... On Tue, Jun 23, 2015 at 4:41 PM, Adrian Prantl <aprantl at apple.com> wrote: > Here is a proposal for improving DbgValueHistoryCalculator and the > overall quality of debug locations. > > Focus: This is about lowering the DBG_VALUE machine instructions to > DWARF location...
2016 May 11
2
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
> On May 11, 2016, at 1:12 PM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Hello, > > Regarding the problem of debug range for optimized code. > Currently a DEBUG_VALUE will be inserted after the <def>vregX > DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem. > Why not simply iterate over all uses
2016 May 11
2
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
> 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
2016 May 11
3
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
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
2018 May 07
2
[DbgInfo] Potential bug in location list address ranges
...*cpt--; > return 0x55; > } > } > > return 0x55; > } > > @paul: Yes you are right, I have investigated the backend and it all > starts at *IfConversionPass*. *r4* is clobbered by *poplt*, and there's > no logic to handle conditional instruction in *DbgValueHistoryCalculator*, > thus the issue at the binary level. > > Son Tuan Vu > > On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com> wrote: > >> As Adrian said, we'd need to see the source of foo() to assess what the >> location-list for bar ought to be. >> >&gt...
2018 Apr 27
0
[DbgInfo] Potential bug in location list address ranges
...*cpt = 3; return 0xAA; } else { *cpt--; return 0x55; } } return 0x55; } @paul: Yes you are right, I have investigated the backend and it all starts at *IfConversionPass*. *r4* is clobbered by *poplt*, and there's no logic to handle conditional instruction in *DbgValueHistoryCalculator*, thus the issue at the binary level. Son Tuan Vu On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com> wrote: > As Adrian said, we'd need to see the source of foo() to assess what the > location-list for bar ought to be. > > Without actually going to look, I would g...
2016 May 12
2
[LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator
> On May 12, 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors
2018 Apr 27
2
[DbgInfo] Potential bug in location list address ranges
...correct in some cases, they can't rely on any of the debug info to be correct. -- adrian If the conditional instruction poplt was addlt r4, r0, 3 for example, what should be the correct location list of bar? For now, my only idea is to check if the clobbering MI is a conditional return in DbgValueHistoryCalculator which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. Looking forward to hearing your thoughts on this, Thank you for reading this, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://l...
2018 May 07
0
[DbgInfo] Potential bug in location list address ranges
...else { > *cpt--; > return 0x55; > } > } > > return 0x55; > } > > @paul: Yes you are right, I have investigated the backend and it all starts at IfConversionPass. r4 is clobbered by poplt, and there's no logic to handle conditional instruction in DbgValueHistoryCalculator, thus the issue at the binary level. > > Son Tuan Vu > > On Fri, Apr 27, 2018 at 5:53 PM, <paul.robinson at sony.com <mailto:paul.robinson at sony.com>> wrote: > As Adrian said, we'd need to see the source of foo() to assess what the location-list for bar ought to b...
2018 Apr 27
2
[DbgInfo] Potential bug in location list address ranges
..., I'd expect to read the value of *bar* from *r4* in the remaining of the function. If the conditional instruction *poplt *was *addlt r4, r0, 3* for example, what should be the correct location list of *bar*? For now, my only idea is to check if the clobbering MI is a *conditional return* in *DbgValueHistoryCalculator* which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. Looking forward to hearing your thoughts on this, Thank you for reading this, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://l...
2018 Apr 27
0
[DbgInfo] Potential bug in location list address ranges
...ses, they can't rely on any of the debug info to be correct. -- adrian > > If the conditional instruction poplt was addlt r4, r0, 3 for example, what should be the correct location list of bar? > > For now, my only idea is to check if the clobbering MI is a conditional return in DbgValueHistoryCalculator which computes the end address of a location llist entry. But I do not feel like this is the correct fix though. > > Looking forward to hearing your thoughts on this, > > Thank you for reading this, > > Son Tuan Vu -------------- next part -------------- An HTML attachment was...
2016 Jul 29
3
IR @llvm.dbg.value entries for variables when a phi node has been created
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
2015 Jul 29
1
[LLVMdev] Error when i am using command make -j4 command in cygwin to compile safecode
...elease+Asserts build llvm[3]: Compiling X86MachineFunctionInfo.cpp for Release+Asserts build llvm[3]: Compiling LoopInstSimplify.cpp for Release+Asserts build llvm[3]: Compiling IPA.cpp for Release+Asserts build llvm[3]: Compiling X86PadShortFunction.cpp for Release+Asserts build llvm[3]: Compiling DbgValueHistoryCalculator.cpp for Release+Asserts build llvm[3]: Compiling InlineCost.cpp for Release+Asserts build llvm[3]: Compiling LoopInterchange.cpp for Release+Asserts build llvm[3]: Compiling DebugLocStream.cpp for Release+Asserts build llvm[3]: Compiling X86RegisterInfo.cpp for Release+Asserts build llvm[3]: Compil...