This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH,RFC 0/3] Support for CTF in GCC
On 05/22/2019 02:04 AM, Richard Biener wrote:
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.
OK. So I wonder how difficult it is to emit CTF by walking dwarf2outs own
data structures? That is, in my view CTF should be emitted by
dwarf2out_early_finish () (which is also the point LTO type/decl debug
is generated from). It would be nice to avoid extra bookkeeping data structures
for CTF since those of DWARF should include all necessary information already.
CTF format has some characteristics which make it necessary to "pre-process"
the generated CTF data before asm'ing out into a section. E.g. few cases of why
"pre-processing" CTF is required before asm'ing out :
1. CTF types do need to be emitted in "some" order :
CTF types can have references to other CTF types. This consequently implies
that the referenced type must appear BEFORE the referring type.
2. CTF preamble holds offsets to the various subsections - function info,
variables, data types and CTF string table. To calculate the offsets, the
compiler needs to know the size in bytes of these sub-sections. CTF
representation for some types like structures, functions, enums have
variable length of bytes trailing them (depending on the defintion of the
type).
3. CTF variable entries need to be placed in the order of the names.
Because of some of these "features" of the CTF format, the compiler does need
to do a transition from runtime CTF generated data --> CTF binary data format
for a clean and readable code.
So, I think the needs are different enough to vouch for an implementation
segregated from dwarf* codebase.
Btw, do I read the CTF document posted to the binutils list (but not
cross-referenced
here :/) correctly in that you only want CTF debug for objects defined
in the file and
type information for the types refered to from that? At
Yes. CTF is emitted for types at file-scope and global-scope only. Types, vars
at function-scope should be skipped.
dwarf2out_early_finish time
it isn't fully known which symbols will end up being emitted (and with
LTO you only
would know at link time).
In nutshell, I am processing all decl at early_global_decl () time except
TYPE_DECL (Similar to DWARF, based on the thinking that if they are required
they will be reached at via other DECL).
In addition, I process all decl at type_decl () time except function-scope,
no-name decl, builtins.
Currently, it does look like CTF for possibly to-be-omitted symbols will be
generated... I assume even DWARF needs to handle this case. Can you point me to
how DWARF does this ?
It seems to me that linker support to garbage collect
unused entries would be the way to go forward (probably easy for the
declarations
but not so for the types)?
Hmm, garbage collecting unused types in linker - Let me get back to you on
this. It does not look easy. Decl should be doable though.