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

[Indu Bhagat <indu.bhagat@oracle.com>]

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 ?