similar to: Filename's in DIBuileder

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 all, I haven't seen a proposal for an optimised-code debugging experience Round Table yet so here goes! Please let me know if you are interested by emailing me at: orlando.hyams at sony.com Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end

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

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

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

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

On Wed, Dec 7, 2016 at 3:39 PM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > >> I don't know what the right, if any, solution to this is - but I > >> thought I should bring it up in case you or anyone else wanted to > >> puzzle it over & see if the competing needs/desires might need to be > >> considered. > > One thing

----- Original Message ----- > From: "Andrea Di Biagio" <andrea.dibiagio at gmail.com> > To: "Paul Robinson" <paul.robinson at sony.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "David Blaikie" > <dblaikie at gmail.com>, llvm-dev at lists.llvm.org > Sent: Thursday, December 15, 2016 9:05:00 AM > Subject: Re:

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger

I'm not familiar with the target instruction set, but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake. The line table does

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

>> I don't know what the right, if any, solution to this is - but I >> thought I should bring it up in case you or anyone else wanted to >> puzzle it over & see if the competing needs/desires might need to be >> considered. > One thing that I recall being discussed was changing the way that we > set the is_stmt flag in the DWARF line-table information. As I

Hello, A recent series of commits, ending with r169304 and relating to PR13303, add is_stmt to line entries for functions. This appears to be to work around problems with gdb. However, I observe is_stmt is not always applied to line entries for functions. This may only affect the arm backend. Compiling the same code with the aarch64 backend does not demonstrate this problem. It seems that

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

Hi paulr Thanks for your reply. Though DWARF info give me the code address ranges, there might be inline data. If so, how to handle this case? As for the dwarf line table. Sometimes, the source line might be zero. Do you know why? If all instructions should be describe in the line table, I think analyzing Dwarf line table is enough to get all the instructions addresses. Do you agree? I would

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude