[Dwarf-Discuss] What does an "<artificial>" file name mean?

[Jakub Jelinek]

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