search for: dw_tag_compile_unit

...y, let me correct that: the assembler does generate the .debug_info section (as well as line number data) when run with "-g". I was wrong, sorry. The issue I am having with GDB is occurring because using ".file" directives with LLVM's assembler doesn't automatically add DW_TAG_compile_unit DIEs to the .debug_info and .debug_aranges sections. (It does with GAS.) When the assembler is run with -g, it does generate the DW_TAG_compile_unit DIEs. There is no problem there. The problem comes when you want to manually include your own debug data using assembler directives. This is useful w...

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

...> f2(); > > } > > inl2.cpp: > > #include "inl.h" > > void c2() { > > f2(); > > } > > > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > > > DW_TAG_compile_unit > > DW_AT_name "inl1.cpp" > > DW_TAG_subprogram #0 > > DW_AT_name "f2" > > DW_TAG_subprogram > > DW_AT_name "c1" > > DW_TAG_inlined_subroutine > > DW_TAG_abstract_origin #0 "f2" > > DW_TA...

...pp: > #include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...the existence of foo.xx, the original source file. I have compiled a small helloworld.c program, and compared the debug info in helloworld and foo, using 'readelf --debug-dump'. I have noticed that in helloworld, the .debug_aranges section has 2 address ranges, - one pointing to a DW_TAG_compile_unit referencing the /sysdeps/i386/elf/start.S file - the other pointing to a DW_TAG_compile_unit with the helloworld,c file. However, in the foo program, the .debug_aranges section has only 1 address range, pointing to a DW_TAG_compile_unit referencing the /sysdeps/i386/elf/start.S file. The se...

...nline __attribute__((always_inline)) void f2() { f1(); } inl1.cpp: #include "inl.h" void c1() { f2(); } inl2.cpp: #include "inl.h" void c2() { f2(); } Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking: DW_TAG_compile_unit DW_AT_name "inl1.cpp" DW_TAG_subprogram #0 DW_AT_name "f2" DW_TAG_subprogram DW_AT_name "c1" DW_TAG_inlined_subroutine DW_TAG_abstract_origin #0 "f2" DW_TAG_compile_unit DW_AT_name "inl2.cpp" DW_TAG_subprogram #1 DW_A...

...pe definition is known to exist in another Module". i.e. DWARFLinker could replace the declaration with the definition. But that problem could be more easily resolved when debug info is generated(probably without significant increase of debug info size): Let`s check the example: 0x0000000b: DW_TAG_compile_unit DW_AT_low_pc (0x0000000000201700) DW_AT_high_pc (0x0000000000201719) 0x0000002a: DW_TAG_subprogram 0x00000043: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x0000000000000086 "_Z1fv") DW_AT_low_pc (0x0000...

...> #include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...> #include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...pp: > #include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...----------------------------- 84 !0 = metadata !{i32 786449, i32 0, i32 4, metadata !"hello.cpp", metadata !"/proj/mtk04456", metadata !"clang version", i1 true, i1 true, metadata !"flag", i32 0, metadata !1, metadata !1, metadata !1, metadata !1} ; [ DW_TAG_compile_unit ] [/p roj/mtk04456/hello.cpp] [DW_LANG_C_plus_plus] ------------------------------------------------------------------------------ First problem happen : DICompileUnit doesn't find the last four metadata (i.e. enums types, retained types, subprograms, global variables). But DIBuilder::Cr...

When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list, and so forth). How can I remove that unused stuff? (It continues on to generated object files, which is extra undesirable when there is a lot of this.) I would have expected that the strip-dead-debug-info pass wou...

...le names excluding the path, so two compilation units that happen > to share a name generate identical source IDs and then attempt to > generate duplicate symbols for labels. The file name does not exclude the path: $ cat a/a.c int a(void) { return 0; } $ clang a/a.c -g -S -o - -flto | grep DW_TAG_compile_unit !0 = metadata !{i32 720913, i32 0, i32 12, metadata !"a/a.c", metadata !"/home/nicholas", metadata !"clang version 3.1 (trunk 146849)", i1 true, i1 false, metadata !"", i32 0, metadata !1, metadata !1, metadata !3, metadata !1} ; [ DW_TAG_compile_unit ] N...

...{ >> f2(); >> } >> inl2.cpp: >> #include "inl.h" >> void c2() { >> f2(); >> } >> >> Compile to IR, llvm-link the result. The DWARF you get is basically the >> same as the DWARF you'd get without linking: >> >> DW_TAG_compile_unit >> DW_AT_name "inl1.cpp" >> DW_TAG_subprogram #0 >> DW_AT_name "f2" >> DW_TAG_subprogram >> DW_AT_name "c1" >> DW_TAG_inlined_subroutine >> DW_TAG_abstract_origin #0 "f2" >> DW_TAG_compil...

...> #include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

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 cond...

...used llvm-dwarfdump and was able to figure >> 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_s...

>From DwarfDebug.cpp: >/// GetOrCreateSourceID - Look up the source id with the given directory and >/// source file names. If none currently exists, create a new id and insert it >/// in the SourceIds map. This can update DirectoryNames and SourceFileNames >/// maps as well. >unsigned DwarfDebug::GetOrCreateSourceID(StringRef FileName, >

...gt; When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR.  (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list, and so forth).  How can I remove that unused stuff?  (It continues on to generated object files, which is extra undesirable when there is a lot of this.) In theory, every metadata that is not attached to a real valu...

...>>> inl2.cpp: >>> #include "inl.h" >>> void c2() { >>> f2(); >>> } >>> >>> Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking: >>> >>> DW_TAG_compile_unit >>> DW_AT_name "inl1.cpp" >>> DW_TAG_subprogram #0 >>> DW_AT_name "f2" >>> DW_TAG_subprogram >>> DW_AT_name "c1" >>> DW_TAG_inlined_subroutine >>> DW_TAG_abstract_origin #0 "f2&...