similar to: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

On Wed, Dec 9, 2015 at 10:40 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be > surprising if we used the typedef (or otherwise non-canonical) name in the > class name): > > > > Finally getting back to this….. Ha. We don't unwrap the typedefs ("name > as

On Wed, Dec 9, 2015 at 11:11 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Actually no, we prefer to have the original typedef names in the > instantiation name, for source fidelity. > Then perhaps you should keep this change in your tree too - since that's where the need is? > "Name as it is in the source" or something reasonably close.

On Wed, Dec 9, 2015 at 11:59 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Maybe we are being too pedantic about the names. I'll have to go back and > look in detail at why we decided to do that. > > > > In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies > to definitions of a type, not declarations. ("Each formal

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, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Adrian, >> >> Thanks for a quick reply! >> >> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>>

Adrian, Thanks for a quick reply! On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Hi, >> >> I'm trying to achieve the following: >> >> - I have a global variable BaseAddress that holds the base address of >> a

On Thu, Mar 22, 2018 at 5:13 PM, Roman Levenstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Adrian, >>> >>> Thanks for a quick reply!

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 Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Adrian, > > Thanks for a quick reply! > > On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Hi, >>>

Hi all, Need your help. I added some debug information to my code according to Kaleidoscope-9 sample and got stuck with a GDB error: (gdb) info functions > invalid dwarf2 offset 1849950870 > My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following:

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

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

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

> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: > > Hi, > > I'm trying to achieve the following: > > - I have a global variable BaseAddress that holds the base address of > a contiguous dynamically allocated memory block. > > - I have a number of logical variables of different types that are > mapped on certain address

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk

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'm trying to achieve the following: - I have a global variable BaseAddress that holds the base address of a contiguous dynamically allocated memory block. - I have a number of logical variables of different types that are mapped on certain address ranges inside the memory block pointed to by BaseAddress. The offset and the size of each such logical variable inside the memory block are