search for: dw_at_comp_dir

...g_str[0x00000000] = "clang version 8.0.1 ") DW_AT_language [DW_FORM_data2] (DW_LANG_C99) DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000) DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 8.0.1 ") Similarly as above snippet .debug_str is always pointing to 0x00000 for everything. >> >> Can you please help me in finding which part of the target(Backend >> files) will construct the dwarf data, esp...

...:~$ 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 163034)") 0x00000022: DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000027: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000044: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang...

..., offset: 0x0): clang > > version 8.0.1 > > <10> DW_AT_language : 12 (ANSI C99) > > <12> DW_AT_name : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <16> DW_AT_stmt_list : 0x0 > > <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <1e> DW_AT_low_pc : 0x0 > > <22> DW_AT_high_pc : 0x6c > > <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) > > <27> DW_AT_low_pc : 0x0 > >...

...ile_unit > .int Linfo_string0 # DW_AT_producer > .short 12 # DW_AT_language > .int Linfo_string1 # DW_AT_name > .int 0 # DW_AT_low_pc > .int Lsection_line # DW_AT_stmt_list > .int Linfo_string2 # DW_AT_comp_dir > .byte 2 # Abbrev [2] 0x22:0x5d DW_TAG_subprogram > .int Linfo_string3 # DW_AT_name > .byte 1 # DW_AT_decl_file > .byte 2 # DW_AT_decl_line > # DW_AT_prototyped >...

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

...readelf -w exec > log ) There just have one TAG . Number TAG 1 DW_TAG_compile_unit [no children] DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data2 DW_AT_name DW_FORM_strp DW_AT_low_pc DW_FORM_addr DW_AT_stmt_list DW_FORM_data4 DW_AT_comp_dir DW_FORM_strp Unknown AT value: 3fe1 DW_FORM_flag Unknown AT value: 3fe2 DW_FORM_strp I can't find other dwarf TAG in my object file. Is the metadata wrong? Or I loss some step when I generate metadata? If you need my pass's source. Please give me your mail. I will mail it for...

...e_unit) <c> DW_AT_producer : (indirect string, offset: 0x0): clang version 8.0.1 <10> DW_AT_language : 12 (ANSI C99) <12> DW_AT_name : (indirect string, offset: 0x0): clang version 8.0.1 <16> DW_AT_stmt_list : 0x0 <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang version 8.0.1 <1e> DW_AT_low_pc : 0x0 <22> DW_AT_high_pc : 0x6c <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) <27> DW_AT_low_pc : 0x0 <2b> DW_AT_high_pc : 0x6c <2f>...

...empSymbol("section_line")); else - addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4, 0); + addSectionOffset(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_addr, + Asm->GetTempSymbol("section_line")); if (!Dir.empty()) addString(Die, dwarf::DW_AT_comp_dir, dwarf::DW_FORM_string, Dir); You probably wanted to do... @@ -1904,8 +1913,8 @@ // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. if (Asm->MAI->doesDwarfUsesAbsoluteLabelForStmtList()) - addLabel(Die, dwarf::DW_AT_stmt_l...

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

The failure is a bit odd. LLVM is ignoring $PWD because it doesn't have the same inode as '.'. This causes the test failure because DW_AT_comp_dir and $PWD differ. However, $PWD and '.' should be the same inode since $PWD is a symlink to the current directory and stat() looks through symlinks. > Since this latest board only has two cores, it will run slower and it will need to have the -j6 changed to -j2. I'll make that chang...

On Feb 24, 2011, at 11:36 AM, Devang Patel wrote: > > On Feb 12, 2011, at 2:07 AM, Nathan Jeffords wrote: > >> Hello All, >> >> I have created a set of patches that get dwarf debugging support working for the COFF object file. I also believe I have fixed what appears to be a bug in how line info sections are referred to from the DW_TAG_compile_unit DIE. I have run

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

..._30/final)" # DW_AT_producer .byte 0 .short 12 # DW_AT_language .ascii "a.c" # DW_AT_name .byte 0 .long 0 # DW_AT_entry_pc .long .Lsection_line # DW_AT_stmt_list .ascii "/home/marco/clang_issue" # DW_AT_comp_dir .byte 0 .byte 2 # Abbrev [2] 0x5c:0x7 DW_TAG_base_type .ascii "int" # DW_AT_name .byte 0 .byte 5 # DW_AT_encoding .byte 4 # DW_AT_byte_size .byte 3 # Abbrev [3] 0x63:0x18 DW_TA...

Dear LLVM devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but

This buildbot seems to have been failing continuously for a couple of weeks now ( http://lab.llvm.org:8011/builders/llvm-mips-linux/builds/14658 ) - is anyone watching it/caring about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at 11:34 PM Subject: buildbot failure in LLVM on llvm-mips-linux To: Ahmed Bougacha

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

...> .short 12 # DW_AT_language > > .int Linfo_string1 # DW_AT_name > > .int 0 # DW_AT_low_pc > > .int Lsection_line # DW_AT_stmt_list > > .int Linfo_string2 # DW_AT_comp_dir > > .byte 2 # Abbrev [2] 0x22:0x5d > DW_TAG_subprogram > > .int Linfo_string3 # DW_AT_name > > .byte 1 # DW_AT_decl_file > > .byte 2 # DW_AT_decl_line > >...

On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dblaikie at gmail.com> wrote: > > Yeah, not sure - you mention the linker produces errors, but the errors you showed looked like objdump errors? Were those errors from trying to dump the linked executable, and not errors that were produced by the linker itself? Yes, as mentioned earlier I was able to generate final executable but it