search for: dw_at_languag

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, th...

Peter, On Feb 23, 2011, 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 > b...

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

...t) > > 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, offset: 0x0): clang > > version 8.0.1 >...

...umber > .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 [2] 0x22:0x5d DW_TAG_subprogram > .int Linfo_stri...

...DW_AT_encoding [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 ch...

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

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

...t; > 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...

...ight 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 other dwarf TAG in my object file....

...g 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, offset: 0x0): clang version 8.0.1 <1e> DW_AT_low_pc : 0x0 <22&gt...

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

...main.cpp #include "struct.h" int test1(); int test2(); int main ( void ) {   test1();   test2();   return 0; } $ clang++ main.cpp mod1.cpp mod2.cpp -O -g -fno-inline $ llvm-dwarfdump -a a.out.dSYM/Contents/Resources/DWARF/a.out | less 0x00000056: DW_TAG_compile_unit               DW_AT_language    (DW_LANG_C_plus_plus)               DW_AT_name        ("mod1.cpp")​ 0x000000ae:   DW_TAG_structure_type <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<                 DW_AT_name      ("foo&q...

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

..._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 # Abbrev [2] 0x5c:0x7 DW_TAG_base_t...

...riple, Path); 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, 0...

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

...tatic bool is_fortran (void); static bool is_ada (void); @@ -5493,6 +5491,16 @@ return lang == DW_LANG_C_plus_plus || lang == DW_LANG_ObjC_plus_plus; } +/* Return TRUE if the language is objc. */ + +static inline bool +is_objc (void) +{ + unsigned int lang = get_AT_unsigned (comp_unit_die, DW_AT_language); + + return lang == DW_LANG_ObjC; +} + /* Return TRUE if the language is Fortran. */ static inline bool @@ -8615,7 +8623,7 @@ /* APPLE LOCAL begin Radar 5741731, typedefs used in '@try' blocks */ if (is_volatile_type - && c_dialect_objc () + &&...

...nitSuccess); > 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...