similar to: GDB doesn't work with IR-originated debug info

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

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

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

llvm-dwarfdump currently outputs the offset of each DIE relative to the entire debug_info section. But type/DIE references within a unit are relative to that unit. Should we emit unit-relative offsets instead? I've prototyped this and end up with output something like this: 0x00000051: DW_TAG_base_type [24] DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000051] =

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had

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

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

Hi, I am wondering if this behavior of creating debug info is correct. A type in compile unit entry is pointing to a type under subprogram entry?! This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579 0x0000000b: DW_TAG_compile_unit [1] * 0x00000026: DW_TAG_pointer_type [2] DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})

> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to

Is there any good reason for using DW_FORM_data1 for the DW_AT_language attribute of DW_TAG_compile_unit? This prevents using language codes in the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. I think the obvious change to use DW_FORM_data2 in line 1897 of lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are binary compatibility issues, the abbrev form could be chosen

> On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: Greg Clayton [mailto:gclayton at apple.com] >> Sent: Thursday, November 17, 2016 5:01 PM >> To: David Blaikie >> Cc: llvm-dev at lists.llvm.org; Robinson, Paul; Eric Christopher; Adrian >> Prantl >> Subject: Re:

I am experiencing an issue combining bitcode files for the purpose of generating the combined bitcodes as a single bitcode file. I would like to have any pointers to help me debug this or maybe it has been seen before and a fix is either being worked on or is done. I am using the Xcode 9.0 compiler. I believe the Swift code is 3.x. I have reproduced this using the tot llvm-link. The input

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

06.11.2017 14:56, Robinson, Paul пишет: >> Hi everybody, >> As you know, Cuda/NVPTX target has very limited support of the debug >> info in Clang/LLVM. Currently, LLVM supports only emission of the line >> numbers debug info. >> This is caused by limitations of the Cuda/NVPTX codegen. Clang/LLVM >> translates the source code to LLVM IR, which is then lowered to