On 4/29/21 1:02 PM, Indu Bhagat wrote:
+{
+ dw_die_ref c;
+
+ if (!ctf_do_die (die))
+ return;
+
+ FOR_EACH_CHILD (die, c, ctf_do_die (c));
+}
+
/* Perform any cleanups needed after the early debug generation pass
has run. */
@@ -32471,6 +32491,16 @@ dwarf2out_early_finish (const char *filename)
print_die (comp_unit_die (), dump_file);
}
+ /* Generate CTF debug info. */
+ if ((ctf_debug_info_level > CTFINFO_LEVEL_NONE
+ || btf_debug_info_level > BTFINFO_LEVEL_NONE) && lang_GNU_C ())
+ {
+ ctf_debug_init ();
+ debug_format_do_cu (comp_unit_die ());
+ for (limbo_die_node *node = limbo_die_list; node; node =
node->next)
+ debug_format_do_cu (node->die);
+ }
+
Since you have support to copy .ctf sections for LTO you have to write
those here. And you have to care for fat LTO objects which for dwarf
results in two sets of .debug_info - I suppose for CTF you can share
the section for the fat and the LTO part though? So why are you
writing the CFT debug in dwarf2out_finish now?
The change to writing CTF/BTF debug information in dwarf2out_finish
instead of dwarf2out_early_finish, at this time, was driven by the needs
of BTF. A BTF section has entries of kind BTF_KIND_DATASEC which
essentially give information about which section a variable is in (.bss,
.rodata, .text). This information is available later on in the
compilation process and hence, BTF needed a longer lifetime of the CTF
container to update the information in the CTF container. In general,
keeping any future needs that may come up, it seemed like a better
design point to defer the ctf_debug_finalize to dwarf2out_finish
(assuming we work out it out with LTO).
Umm..what I wrote wrt BTF was incorrect. The larger lifetime of CTF
container is currently needed specifically for the BPF CO-RE
relocations. They will be generated in the BPF backend, but only at
'expand' time, which is much later than when dwarf2out_early_finish
happens. Strictly speaking, for BTF only (without BPF CO-RE support,
which will go in .BTF.ext) it is not necessary.
Can you elaborate on what it means to say "we have two sets of
.debug_info for fat LTO objects" ?
I am also lost a bit by the comment on "share the section for the fat
and LTO part though". If it helps, from what I can reason, I can add
that I do not see how in LTO mode, the CTF of a compilation unit will
shift at all between the compile phase and the LTO phase. This should be
true for CTF V3 atleast. But for V4, this may not be true...
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 ?
