Thanks for your feedback. Comments inline.
On 05/21/2019 03:28 AM, Richard Biener wrote:
GCC RFC patch set :
Patch 1 is a simple addition of a new function lang_GNU_GIMPLE to check for
GIMPLE frontend.
I don't think you should need this - the GIMPLE "frontend" is intended for
unit testing only, I wouldn't like it to be exposed more.
When using -gt with -flto, I would still like the CTF hooks to be initialized
so that CTF can be generated when -flto is used. So the check in toplev.c is
done to allow only C and GNU GIMPLE. I am fine with doing a string compare
with the language.hooks string if you suggest to go that way.
One of the main high-level design requirements that is relevant in the context
of the current GCC patch set is that - CTF and DWARF must be able to co-exist.
A user may want CTF debug information in isolation or with other debug formats.
A .ctf section is small and unlike other debug sections, ideally should not
need to be stripped out of the binary/executable.
High-level proposed plan (phase 1) :
In the next few patches, the functionality to generate contents of the CTF
section (.ctf) for a single compilation unit will be added.
Once CTF generation for a single compilation unit stabilizes, LTO and CTF
generation will be looked at.
Feedback and suggestions welcome.
You probably got asked this question multiple times already, but,
can CTF information be generated from DWARF instead?
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.
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).
2. Performance problems: the conversion from DWARF to CTF can take a long time,
especially in big programs such as the Linux kernel.
3. Maintainability problems: the converter should be maintained in order to
reflect potential changes in the DWARF generated by the compiler.
4. Adoption problem: it is difficult for applications to adopt the usage of
CTF, even if it happens to provide what they need, since it would require to
write a conversion utility or integrate DTrace's.
The meaning of the CTF acronym suggests that there's nothing
like locations, registers, etc. but just a representation of the
types?
Yes. CTF is simply put Type information; no locations, registers etc.
Generally we are trying to walk away from supporting multiple
debug info formats because that gets in the way of being
more precise from the frontend side. Since DWARF is the
With regard to whether the support for CTF imposes infeasible or distinct
requirements on the frontend - it does not appear to be the case (I have
been working on CTF generation in GCC for a SINGLE compilation unit; More see
below). I agree that CTF debug information generation should ideally not impose
additional requirements on the frontend.
defacto standard, extensible and with a rich feature set the
line of thinking is that other formats (like STABS) can be
generated by "post-processing" DWARF. Such
post-processing could happen on the object files or
on the GCC internal DWARF data structures by
providing alternate output routines. That is, the mid-term
design goal is to make DWARF generation the "API"
for GCC frontends to use when creating high-level
debug information rather than trying to abstract from
the debuginfo format via the current debug-hooks or
the other way around via language-hooks.
I am not sure if I understood the last part very well, so I will state how CTF
generation is intended to work. Does the following fit the design goal you
state ?
( Caveat : I have been working on the functionality to generate CTF for a SINGLE
compilation unit. LTO bits remain. )
So far, there are no additional requirements on the frontend side. CTF hooks
are wrappers around DWARF debug hooks (much like go-dump hooks, and vms dbg
hooks). We did notice that GCC does not have the infrastructure to register or
enlist multiple debug hooks; and now from your comments it is clear that this
is by design. Thanks for clarifying that.
Having said that, I use CTF hooks to go from TREE --> update CTF internal
structures or output CTF routines depending on the hook (e.g., type_decl or
finish respectively), rather than changing the dwarf* files with CTF APIs. The
CTF debug hooks relay control to the DWARF debug hooks at an appropriate point.
TREE input references to the CTF debug hooks are readonly in the context of CTF
generation.
The CTF debug information is kept in a CTF container distinct from the frontend
structures. HashMaps are used to avoid generation of duplicate CTF and to
book-keep the generated CTF.
