We're in the final stages of finalizing the DWARF v5 spec, which will
include the Fission extensions. When that's done, we'll start
converting GCC and gold over to use the official DWARF features rather
than the GNU extensions.
>> + The "Fission" project was started in response to the problems caused by
>> huge amounts of debug information in large applications. By splitting the
>> debug information into two parts at compile time -- one part that remains in
>> the .o file and another part that is written to a parallel .dwo ("DWARF
>> object") file -- we can reduce the total size of the object files processed
>> by the linker.
>
> Yay, a quite noticeable link-time speedup! \o/
Good!
>> + Fission is implemented in GCC 4.7, and requires support from recent
>> versions of objcopy and the gold linker.
>
> Is my understanding correct that the gold linker is not actually a
> requirement -- at least nowadays? In my (very limited, so far) testing,
> this also seems to work with ld.bfd. (I do see objcopy's --extract-dwo
> and --split-dwo options being used in gcc/gcc.c:ASM_FINAL_SPEC, so I
> suspect that's what "recent versions of objcopy" hints at?)
Yes, that's what we need from objcopy.
The reason gold is needed is for the --gdb-index option. Without the
.gdb_index section, gdb has to load all the .dwo files at startup so
that it knows all the symbols; with the .gdb_index section, it can
find symbols in the index and load the necessary .dwo file(s) on
demand. On a large project, I'd still expect absence of an index to be
painful enough that I'd leave that requirement in the wiki.
>> + Use the {{{-gsplit-dwarf}}} option to enable the generation of split DWARF
>> at compile time. This option must be used in conjunction with {{{-c}}};
>> Fission cannot be used when compiling and linking in the same step.
>
> According to the following -- admittedly very minimal -- testing, this is
> not actually (no longer?) true?
>
> $ [gcc] [...] -gsplit-dwarf
> $ ls *.dwo
> ccF9JYjE.dwo subroutines.dwo
> $ gdb -q a.out
> Reading symbols from a.out...done.
> (gdb) list main
> [...]
> (gdb) quit
> $ rm *.dwo
> $ gdb -q a.out
> Reading symbols from a.out...
> warning: Could not find DWO CU subroutines.dwo(0x2d85cdd539df6900)
> referenced by CU at offset 0x0 [in module [...]/a.out]
>
> warning: Could not find DWO CU ccF9JYjE.dwo(0xa6936555a636518) referenced
> by CU at offset 0x35 [in module [...]/a.out]
> done.
> (gdb) list main
> warning: Could not find DWO CU subroutines.dwo(0x2d85cdd539df6900)
> referenced by CU at offset 0x0 [in module [...]/a.out]
>
> Have I been testing the wrong thing?
Hmmm, I think the problem here is that the .dwo files corresponding to
the temporary .o files will never get cleaned up, and might even get
overwritten unpredictably. It's just not a fully-supported path. I may
have forgotten some other issues. I may have also been expecting them
to get automatically cleaned up when the .o was removed.
>> + Use the gold linker's {{{--gdb-index}}} option ({{{-Wl,--gdb-index}}} when
>> linking with gcc or g++) at link time to create the .gdb_index section that
>> allows GDB to locate and read the .dwo files as it needs them.
>
> Unless told otherwise, I'll re-word that to the effect that gold, and
> usage of its --gdb-index option are optional.
Maybe "highly recommended" would be better.
-cary
