search for: dw_form_data2

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 conditionally. Are there? Thanks -Peter S. Housel- housel at acm.org

...1, at 1:32 PM, Peter Housel wrote: > 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 > conditionally. Are there? I do not see any binary compatibility issue. In any case, if there are any I'd learn them about soon! Chec...

...coding [DW_FORM_data1] (0x05) DW_AT_byte_size [DW_FORM_data1] (0x04) 0x00000058: NULL 0x000001ec: Compile Unit: length = 0x0000002b version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000021b) 0x0000000b: DW_TAG_type_unit [25] * DW_AT_language [DW_FORM_data2] (0x0004) 0x0000000e: DW_TAG_namespace [9] * It is a bit weird using the same syntax to print the section relative offest for the unit header, then unit-relative offsets for the DIEs, but other than that this seems to me like a useful improvement. (I was going to use this change to help me...

...rate 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 manually on my IR without complaint. However, I am not able t...

...f 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 manually on my IR without complaint....

....byte 17 # DW_TAG_compile_unit > .byte 1 # DW_CHILDREN_yes > .byte 37 # DW_AT_producer > .byte 14 # DW_FORM_strp > .byte 19 # DW_AT_language > .byte 5 # DW_FORM_data2 > .byte 3 # DW_AT_name > .byte 14 # DW_FORM_strp > .byte 17 # DW_AT_low_pc > .byte 1 # DW_FORM_addr > .byte 16 # DW_AT_stmt_list > .byte 6 # DW_FORM_...

...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 other dwarf TAG in my object file. Is the metadata wro...

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

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

...EXPECT_TRUE(DwarfInitSuccess); uint16_t Version = 4; uint8_t AddrSize = 8; DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); DwarfGenDIE CUDie = CU.getUnitDIE(); CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); SubprogramDie.addAttribute(DW_AT_high_pc, DW_FORM_addr, 0x2000U); Dwa...

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

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List

...; uint16_t Version = 4; > uint8_t AddrSize = 8; > DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); > DwarfGenDIE CUDie = CU.getUnitDIE(); > > CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); > CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); > > DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); > SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); > SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); > SubprogramDie.addAttribute(DW_AT_high_pc, DW_FOR...

...int8_t AddrSize = 8; >>> DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); >>> DwarfGenDIE CUDie = CU.getUnitDIE(); >>> >>> CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); >>> CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); >>> >>> DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); >>> SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); >>> SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); >>> SubprogramDi...

...# Abbreviation Code .byte 17 # DW_TAG_compile_unit .byte 1 # DW_CHILDREN_yes .byte 37 # DW_AT_producer .byte 8 # DW_FORM_string .byte 19 # DW_AT_language .byte 5 # DW_FORM_data2 .byte 3 # DW_AT_name .byte 8 # DW_FORM_string .byte 82 # DW_AT_entry_pc .byte 1 # DW_FORM_addr .byte 16 # DW_AT_stmt_list .byte 6 # DW_FORM_data4 .byte 27...

...; >>> DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); > >>> DwarfGenDIE CUDie = CU.getUnitDIE(); > >>> > >>> CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); > >>> CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C); > >>> > >>> DwarfGenDIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram); > >>> SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main"); > >>> SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); > &gt...

....byte 1 # DW_CHILDREN_yes > > .byte 37 # DW_AT_producer > > .byte 14 # DW_FORM_strp > > .byte 19 # DW_AT_language > > .byte 5 # DW_FORM_data2 > > .byte 3 # DW_AT_name > > .byte 14 # DW_FORM_strp > > .byte 17 # DW_AT_low_pc > > .byte 1 # DW_FORM_addr > > .byte 16 #...

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