[PATCH,RFC 0/3] Support for CTF in GCC

[Indu Bhagat]

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.