On Tue, May 21, 2019 at 03:44:47PM -0700, Indu Bhagat wrote:
> Yes and No :) And that is indeed one of the motivation of the project - to
> allow CTF generation where it's most suited aka the toolchain.
>
> There do exist utilties for generation of CTF from DWARF. For example, one of
> them is the dwarf2ctf in the DTrace Linux distribution. dwarf2ctf works
> offline
> to transform DWARF generated by the compiler into CTF.
So, if there is a conversion utility, why don't we just change gcc so that
if some new option is passed on the gcc driver link line, then that
post-processing utility will be invoked too?
> A dependency of an external conversion utility for "post-processing" DWARF
> offline poses several problems:
>
> 1. Deployment problems: the converter should be distributed and integrated in
> the build system of the program. This, on occasions, can be intrusive.
> For
> example, in terms of dependencies: the dwarf2ctf converter depends on
> libdwarf from elfutils suite, glib2 (used for the GHashTable), zlib (used
> to
> compress the CTF information) and libctf (which both reads and writes the
> CTF data).
I don't see this as a problem.
> 2. Performance problems: the conversion from DWARF to CTF can take a long
> time,
> especially in big programs such as the Linux kernel.
So optimize it? Linux kernel certainly doesn't have extra large debug
information, compared to other projects.
> 3. Maintainability problems: the converter should be maintained in order to
> reflect potential changes in the DWARF generated by the compiler.
If you integrate the support into GCC, then it will need to be maintained
there as well, I bet it will be more work than on the conversion utility.
Jakub
