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.
