similar to: Optimised-code debugging experience Round Table

Hi Eric & Orlando, It’s great to see interest in a lot of different aspects of debug info. At the same time, I’m concerned about a risk to making the topic so broad that we don’t have time to get through all the things people want to get through. I’m thinking there’s a different way to slice the topics, hopefully without much overlap, but that will allow a bit more focus. No doubt a lot of

On Fri, Oct 9, 2020 at 9:38 AM Cazalet-Hyams, Orlando < orlando.hyams at sony.com> wrote: > Hi Reid, > > > > Thanks for sharing this. I plan to work on improving debug-info for > variables > > living in memory as my next "project" so I am very interested to hear with > what > > others have to say about "Idea 1". > > > > There

I chatted with Jeremy Morse, Orlando, and Stephen Tozer at the dev meeting, and wanted to summarize the conversation for our benefit, and to share it with others. I aim to be brief, so I apologize if these notes aren't as helpful as they could be to folks who weren't present. Three project ideas, by priority: 1. Address https://llvm.org/pr34136, improving quality of variable location info

Hi All , We have a scenario in our debugger to handle the file index in the debug_ine info like $llvm-dwarfdump -debug-line test.o file_names[ 1]: name: "test.cpp" dir_index: 0 mod_time: 0x00000000 length: 0x00000000 file_names[ 2]: name: "test.cpp" dir_index: 1 mod_time: 0x00000000 length: 0x00000000

Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

Hi David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

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

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

[+ some folks more knowledgable about the Machine layer than me.] > On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > Hi, > > I am one of the authors of this feature. On Phabricator, we agreed to > take discussion whether encoding this in IR and threading it through the > compiler or performing a late MIR analysis is the better approach.

Hi all, The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with

Hi, [+ Quentin] Sorry for the late reply. > On Feb 13, 2019, at 9:09 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > On 12.02.2019. 18:06, Adrian Prantl wrote: >> [+ some folks more knowledgable about the Machine layer than me.] >> > That would be useful for us too! :) > > >>> On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at

Hi all, As much as possible I would rather we avoid any kind of metadata in MIR to express the semantic of instructions. Instead I would prefer that each back provides a way to interpret what an instruction is doing. What I have in mind is something that would generalize what we do in the peephole optimizer for instance (look for isRegSequenceLike/getRegSequenceInputs and co.) or what we have for

Hi, I found that prologue_end markers where badly placed in my test, and applied https://reviews.llvm.org/D41762 in the hope that it would fix it (I'm on 4.0.1). However, this fix doesn't work for VLIW architectures. At this point we're iterating over bundles, not MachineInstructions, and the FrameSetup flag is set on MachineInstructions, not bundles. If bundling happens in the

It appears to me that from this: https://iis-git.ee.ethz.ch/H2020-Compiler/llvm/commit/1d68fc5021ca8c704e21f171d98bb18eb396a7fa That LLVM basically emits DWARF expressions where is_stmt is true only "once per line". Is that still true? Is there an option to emit more than one per line? Thanks all. -Roger Pack- refs: https://github.com/crystal-lang/crystal/pull/8499

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

Isn't this a typcial situation when the is_stmt field in the DWARF line table should be used? If we set is_stmt=0 for the instruction loading the constant, then a debugger can choose not to stop on that instruction when doing "step" on source level. That way we can keep the original source location for a ConstantSDNode, but also telling the debugger that this isn't a recommended

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test