Displaying 20 results from an estimated 300 matches similar to: "Filename's in DIBuileder"
2020 Sep 01
4
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
2017 Sep 18
5
Interleaved debug info on arm
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
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
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
2020 Sep 22
2
Optimised-code debugging experience Round Table
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
2020 Sep 23
3
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
2014 Feb 18
1
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
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
2014 Feb 18
4
[LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?
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
2018 Jun 21
2
[RFC] Removing debug locations from ConstantSDNodes
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
2019 Dec 17
2
is_stmt and column numbers
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
2016 Dec 15
0
Debug Locations for Optimized Code
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
2016 Dec 15
2
Debug Locations for Optimized Code
----- 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:
2018 Jun 26
2
Instruction boundaries
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
2018 Jun 26
2
Instruction boundaries
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
2018 Aug 09
2
[DWARF] prologue_end fix not working for VLIW
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
2016 Dec 07
6
Debug Locations for Optimized Code
>> 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
2013 Apr 26
0
[LLVMdev] Inconsistent use of is_stmt flag in .debug_line
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
2019 Jan 24
2
[Release-testers] [8.0.0 Release] rc1 has been tagged
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
2018 Jun 26
2
Instruction boundaries
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
2016 Dec 02
2
Libfuzzer depending on uninitialized debug info
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
2014 Feb 20
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
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