search for: dw_at_producer

...ure >> out that debug_info section was incomplete. > > Hi David, Thanks for the reply. > What command did you run, on what file, and what was the output? I ran llvm-dwarf with -verbose option. It gave me the verbose print as below 0x0000000b: DW_TAG_compile_unit [1] * DW_AT_producer [DW_FORM_strp] ( .debug_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]...

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 163034)") 0x00000022: DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version...

...f the debug dump. > > > > Compilation Unit @ offset 0x0: > > Length: 0x6a (32-bit) > > Version: 4 > > Abbrev Offset: 0x0 > > Pointer Size: 4 > > <0><b>: Abbrev Number: 1 (DW_TAG_compile_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 >...

...> .short 2 # DWARF version number > .int L.debug_abbrev_begin # Offset Into Abbrev. Section > .byte 4 # Address Size (in bytes) > .byte 1 # Abbrev [1] 0xb:0x8d DW_TAG_compile_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...

...All seems to work well, except that I am unable to generate debug information. However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: Contents of the .debug_abbrev section: Number TAG (0x0) 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_stmt_list DW_FORM_sec_offset DW_AT value: 0 DW_FORM value: 0 The IR generated for 3.9.0 passes the IR verifier without complaint (including the debug into verifier). I can run llc manuall...

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

...unable to generate debug information. > > However, if I run objdump -g on the generated object file, it reports that the compile unit has no children: > > Contents of the .debug_abbrev section: > > Number TAG (0x0) > 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_stmt_list DW_FORM_sec_offset > DW_AT value: 0 DW_FORM value: 0 > > The IR generated for 3.9.0 passes the IR verifier without complaint (including the debug into ve...

...replace those four metadata with right MDNode. But when I compile my new bitcode to elf file. ( clang++ -g hello.bc -o exec) I can't find my debug info when I use readelf. ( 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 ot...

...0): clang version 8.0.1, instead of variable names. Below is a sample output of the debug dump. Compilation Unit @ offset 0x0: Length: 0x6a (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 4 <0><b>: Abbrev Number: 1 (DW_TAG_compile_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,...

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

...# DWARF version number .long .Labbrev_begin # Offset Into Abbrev. Section .byte 4 # Address Size (in bytes) .byte 1 # Abbrev [1] 0xb:0x130 DW_TAG_compile_unit .ascii "clang version 3.0 (tags/RELEASE_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...

> On Oct 27, 2016, at 6:38 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Oct 27, 2016 at 5:39 PM, Maxime Chevalier-Boisvert via > llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> We’d like to keep track of which clang version was used to build our LLVM binaries. We use cmake and ninja with clang to build.

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

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

...er > > .int L.debug_abbrev_begin # Offset Into Abbrev. Section > > .byte 4 # Address Size (in bytes) > > .byte 1 # Abbrev [1] 0xb:0x8d > DW_TAG_compile_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...

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