On Wed, Nov 09, 2022 at 08:54:00AM -0500, John DelSignore via Dwarf-Discuss wrote: > On Ubuntu 22.04, the Python 3.9 DWARF debug information has compilation units > that look like this: > > Compilation Unit @ offset 0x0: > Length: 0x1a14a (32-bit) > Version: 5 > Unit Type: DW_UT_compile (1) > Abbrev Offset: 0x0 > Pointer Size: 8 > <0><c>: Abbrev Number: 27 (DW_TAG_compile_unit) > <d> DW_AT_producer : (indirect string, offset: 0x3a): GNU GIMPLE > 11.2.0 -mtune=generic -march=x86-64 -g -Og -Og -Og -fno-openmp -fno-openacc > -fcf-protection=full -ffat-lto-objects -fltrans -fno-PIE > <11> DW_AT_language : 12 (ANSI C99) > <12> DW_AT_name : (indirect line string, offset: 0x0): > <artificial> > <16> DW_AT_comp_dir : (indirect line string, offset: 0xd): > /build/python3.9-gIt5iY/python3.9-3.9.14/build-debug > <1a> DW_AT_low_pc : 0x422e96 > <22> DW_AT_high_pc : 0xbf8c > <2a> DW_AT_stmt_list : 0x0 > > Notice that the DW_AT_name attribute for the CU is "<artificial>". The > .debug_line info has the same file name: > > The Directory Table (offset 0x22, lines 11, columns 1): > Entry Name > 0 (indirect line string, offset: 0xd): > /build/python3.9-gIt5iY/python3.9-3.9.14/build-debug > ...SNIP... > > The File Name Table (offset 0x54, lines 23, columns 2): > Entry Dir Name > 0 0 (indirect line string, offset: 0x0): <artificial> > ...SNIP... > > Does anyone know what an "<artificial>" file name is supposed to mean?
The way LTO works in GCC for debug info is that a DW_TAG_compile_unit is produced normally for source files early, but those cover only stuff found in the source unrelated to actual code generation (what functions/variables/types exist etc., if vars have constant values that can appear there too). This is then streamed together with the IL bytecode into *.o files (for FAT LTO together with normal .debug_* sections and code). When a program is linked, for FAT LTO one has always the option to just ignore the IL bytecode and corresponding debug info and link normally, otherwise a linker plugin invokes the compiler which does inter-TU optimizations, if needed split into multiple compilations for different partitions of the callgraph. The compiler doesn't rewrite the already emitted debug info, but instead those compilations then produce these <artificial> DW_TAG_compile_units, which refer to the DIEs in the source CUs and ammend them with code generation related stuff (DW_AT_{low,high}_pc, ranges, locations, everything else that depends on what exact code has been generated). Rewriting the previously emitted debug info would be more costly, but more importantly, different DIEs from those can have code emitted in different partitions (i.e. different compiler invocations), so the different invocations then would need to cooperate on reconstructing the final debug info. Or another tool like dwz could take what is emitted and rewrite the whole debug info to undo the LTO effects. Jakub _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org