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

[Michael Matz <matz at suse dot de>]

Hello,

On Thu, 23 May 2019, Indu Bhagat wrote:

> > 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.

Sure, but this whole process could still be triggered from within 
dwarf2out_early_finish, by walking the DWARF tree (instead of getting fed 
types and decls via hooks) and generating the appropriate CTF data 
structures.  (It's just a possibility, it might end up uglier that using 
GCC trees)

Imagine a world where debug hooks wouldn't exist (which is where we would 
like to end up in a far away future), how would you then add CTF debug 
info to the compiler (assuming it already emits DWARF)?  You would hook 
yourself either into the DWARF routines that currently are fed the 
entities or you would hook yourself into somewhere late in the pipeline 
where the DWARF debug info is complete and you would generate CTF from 
that.

> So, I think the needs are different enough to vouch for an implementation
> segregated from dwarf* codebase.

Of course.  We are merely discussing of where the triggering of processing 
starts: debug hooks, or something like:

dwarf2out_early_finish() {
  ...
  if (ctf)
    ctf_emit();
}

(and then in addition if the current DWARF info would be the source of CTF 
info, or if it'd be whatever the compiler gives you as trees)

The thing is, with debug hooks you'd have to invent a scheme of stacking 
hooks on top of each other (because we want to generate DWARF and CTF from 
the same compilation).  That seems like a wasted effort when our wish is 
for the hooks to go away alltogether.


Ciao,
Michael.