Re: [PATCH V7 4/7] CTF/BTF debug formats

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

>> For a moment, for the sake of this question, if we establish that CTF/BTF
>> generation always feeds off DWARF DIEs (so there is no need to access
>> type/decl tree nodes), what will it take to keep LTO support while keeping
>> ctf_debug_finalize in dwarf2out_finish ?
>
> I don't think it's possible without major surgery.  Now, it looks like
> you want to emit .ctf at the LTO compile stage and BTF at the LTRANS
> stage.  Note you do not have access to the CTF data produced at the
> LTRANS stage.  What DWARF has access to is pointers (symbol name + offset)
> to the early DWARF generated DIEs for GCCs tree decls from what it
> adds DW_AT_abstract_origin references and then amending those entities
> with furthr DWARF attributes.
>
> Now, the "major surgery" could for example entail streaming the CTF
> data you produce from compile through WPA to the LTRANS stage.  Or
> alternatively simply reading it from the compile time produced objects
> by means of the DWARF DIE references.  I don't know what kind of (if any)
> references you need to produce from BTF to the CTF data (I suppose they
> might share indexes into a same symbol table...).

I am thinking, given that we have both "early DWARF" and "late DWARF",
we may want to have three init/fini hooks for debug formats instead of
two:

DEBUG_FORMAT_initialize   (called in dwarf2out_early_finish)

[... traverse early DWARF (DEBUG_FORMAT_do_die) ...]

DEBUG_FORMAT_early_finish (called in dwarf2out_early_finish)
DEBUG_FORMAT_finish       (called in dwarf2out_finish)

Note that CTF and BTF share the ctfc internal data structure (which is
built from traversing the early DWARF) but these are otherwise distinct
debug formats: CTF can be completely emitted in ctf_early_finish,
whereas BTF needs additional information that is only available in
ctf_finish.)