Split DWARF support

[Trass3r]

Looks like there's no support atm.

pahole -E does not output anything on an executable built with clang -Og -g -gsplit-dwarf,
and with -gsplit-dwarf -gdwarf-5 it prints

dwarves/dwarf_loader.c

Line 2414 in e38e89e

fprintf(stderr, "%s: DW_TAG_compile_unit, DW_TAG_type_unit or DW_TAG_partial_unit expected got %s!\n",

on a real application.

Here it seems to print nothing:
https://godbolt.org/z/v78azerGT

[acmel]

⬢[acme@toolbox c]$ eu-readelf -winfo foo.o

DWARF section [ 6] '.debug_info' at offset 0x67:
[Offset]
Compilation unit at offset 0:
Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
Unit type: skeleton (4), Unit id: 0xd08fc2806d240400
[ 14] skeleton_unit abbrev: 1
low_pc (addr) .text+000000000000000000 <_Z3fooi>
high_pc (data8) 23 (.bss+000000000000000000)
stmt_list (sec_offset) 0
dwo_name (strp) "foo.dwo"
comp_dir (strp) "/var/home/acme/c"
GNU_pubnames (flag_present) yes
addr_base (sec_offset) address base [ 8]
⬢[acme@toolbox c]$

Humm, DW_TAG_skeleton_unit

First time I see this.... Researching...

[acmel]

The skeleton unit was when I built with g++ (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), if I do it with clang version 14.0.0 (https://github.com/llvm/llvm-project f7e82e4fa849376ea9226220847a098dc92d74a0) I get:

⬢[acme@toolbox c]$ clang++ -g -gsplit-dwarf -c foo.cpp -o foo.o
⬢[acme@toolbox c]$ eu-readelf -winfo foo.o

DWARF section [ 4] '.debug_info' at offset 0x71:
[Offset]
Compilation unit at offset 0:
Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
Unit type: skeleton (4), Unit id: 0xbf7dd2b580176392
[ b] compile_unit abbrev: 1
stmt_list (sec_offset) 0
comp_dir (strp) "/var/home/acme/c"
GNU_pubnames (flag_present) yes
GNU_dwo_name (strp) "foo.dwo"
GNU_dwo_id (data8) 0xbf7dd2b580176392
low_pc (addr) .text+000000000000000000 <_Z3fooi>
high_pc (data4) 23 (.text+0x0000000000000017)
GNU_addr_base (sec_offset) address base [ 0]
⬢[acme@toolbox c]$

a DW_TAG_compile_unit of type "skeleton", and:

⬢[acme@toolbox c]$ pahole foo.o
⬢[acme@toolbox c]$

No output, but then, there are no children on this DW_TAG_compile_unit, or at least eu-readelf can't see it

[acmel]

ok, there is an extra file, extension .dwo:

⬢[acme@toolbox c]$ ls -la foo.*
-rw-r--r--. 1 acme acme 86 Nov 12 14:46 foo.cpp
-rw-r--r--. 1 acme acme 920 Nov 12 14:52 foo.dwo
-rw-r--r--. 1 acme acme 2552 Nov 12 14:52 foo.o
⬢[acme@toolbox c]$ pahole foo.dwo
struct Foo {
bool b; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int                        i;                    /*     4     4 */

/* size: 8, cachelines: 1, members: 2 */
/* sum members: 5, holes: 1, sum holes: 3 */
/* last cacheline: 8 bytes */

};
⬢[acme@toolbox c]$

So there must be a link in foo.o to foo.dwo, lemme see...

[acmel]

yeah, we have:

GNU_dwo_name (strp) "foo.dwo"

So its a matter of looking for this attribute inside DW_TAG_compile_unit and open that file instead.

[acmel]

Furthermore, with g++ we also get an extra file, the only difference is that unknown to pahole DW_TAG_skeleton_unit:

⬢[acme@toolbox split]$ g++ -g -gsplit-dwarf -c foo.cpp -o foo.o
⬢[acme@toolbox split]$ ls -la
total 12
drwxr-xr-x. 1 acme acme 38 Nov 12 14:58 .
drwxr-xr-x. 1 acme acme 188 Nov 12 14:57 ..
-rw-r--r--. 1 acme acme 86 Nov 12 14:46 foo.cpp
-rw-r--r--. 1 acme acme 1376 Nov 12 14:58 foo.dwo
-rw-r--r--. 1 acme acme 3304 Nov 12 14:58 foo.o
⬢[acme@toolbox split]$ pahole foo.o
die__process: DW_TAG_compile_unit, DW_TAG_type_unit or DW_TAG_partial_unit expected got INVALID!
⬢[acme@toolbox split]$ pahole foo.dwo
struct Foo {
bool b; /* 0 1 */

/* XXX 3 bytes hole, try to pack */

int                        i;                    /*     4     4 */

/* size: 8, cachelines: 1, members: 2 */
/* sum members: 5, holes: 1, sum holes: 3 */
/* last cacheline: 8 bytes */

};
⬢[acme@toolbox split]$

[acmel]

The alt_dwarf branch should address this, I'll revisit the examples above and check if it works with them.