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

[Indu Bhagat]

Hi Michael,

On 05/24/2019 06:04 AM, Michael Matz wrote:
> 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)

I think not only is the code messier, but it's also wasted effort if user only
wants to generate CTF.

> 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.
>
When the debug hooks go away, the functionality can be folded in. Much like
above, the ctf proposed implementation will do :

ctf_early_global_decl (tree decl)
{
   ctf_decl (decl);

   real_debug_hooks->early_global_decl (decl);
}

These ctf_* debug hooks wrappers are as lean as shown above.

I do understand now that if debug hooks are destined to go away, all the
implementation which wraps debug hooks (go dump hooks, vms debug hooks,
and now the proposed ctf debug hooks) will need some merging. But to generate
CTF, I think working on type or decl instead of DWARF dies to is a better
implementation because if user wants only CTF, no DWARF trees need to be
created.

This way we keep DWARF and CTF generation independent of each other (as the
user may want either one of these or both).

> Ciao,
> Michael.