On Tue, Aug 24, 2021 at 7:07 PM Indu Bhagat <indu.bha...@oracle.com> wrote:
>
> On 8/18/21 12:00 AM, Richard Biener wrote:
> > On Tue, Aug 17, 2021 at 7:26 PM Indu Bhagat <indu.bha...@oracle.com> wrote:
> >>
> >> On 8/17/21 1:04 AM, Richard Biener wrote:
> >>> On Mon, Aug 16, 2021 at 7:39 PM Indu Bhagat <indu.bha...@oracle.com>
> >>> wrote:
> >>>>
> >>>> On 8/10/21 4:54 AM, Richard Biener wrote:
> >>>>> On Thu, Aug 5, 2021 at 2:52 AM Indu Bhagat via Gcc-patches
> >>>>> <gcc-patches@gcc.gnu.org> wrote:
> >>>>>>
> >>>>>> This patch adds a new target hook to detect if the CTF container can
> >>>>>> allow the
> >>>>>> emission of CTF/BTF debug info at DWARF debug info early finish time.
> >>>>>> Some
> >>>>>> backends, e.g., BPF when generating code for CO-RE usecase, may need
> >>>>>> to emit
> >>>>>> the CTF/BTF debug info sections around the time when late DWARF debug
> >>>>>> is
> >>>>>> finalized (dwarf2out_finish).
> >>>>>
> >>>>> Without looking at the dwarf2out.c usage in the next patch - I think
> >>>>> the CTF part
> >>>>> should be always emitted from dwarf2out_early_finish, the "hooks"
> >>>>> should somehow
> >>>>> arrange for the alternate output specific data to be preserved until
> >>>>> dwarf2out_finish
> >>>>> time so the late BTF data can be emitted from there.
> >>>>>
> >>>>> Lumping everything together now just makes it harder to see what info
> >>>>> is required
> >>>>> to persist and thus make LTO support more intrusive than necessary.
> >>>>
> >>>> In principle, I agree the approach to split generate/emit CTF/BTF like
> >>>> you mention is ideal. But, the BTF CO-RE relocations format is such
> >>>> that the .BTF section cannot be finalized until .BTF.ext contents are
> >>>> all fully known (David Faust summarizes this issue in the other thread
> >>>> "[PATCH, V2 3/3] dwarf2out: Emit BTF in dwarf2out_finish for BPF CO-RE
> >>>> usecase".)
> >>>>
> >>>> In summary, the .BTF.ext section refers to strings in the .BTF section.
> >>>> These strings are added at the time the CO-RE relocations are added.
> >>>> Recall that the .BTF section's header has information about the .BTF
> >>>> string table start offset and length. So, this means the "CTF part" (or
> >>>> the .BTF section) cannot simply be emitted in the dwarf2out_early_finish
> >>>> because it's not ready yet. If it is still unclear, please let me know.
> >>>>
> >>>> My judgement here is that the BTF format itself is not amenable to split
> >>>> early/late emission like DWARF. BTF has no linker support yet either.
> >>>
> >>> But are the strings used for the CO-RE relocations not all present
> >>> already?
> >>> Or does the "CTF part" have only "foo", "bar" and "baz" while the CO-RE
> >>> part wants to output sth like "foo->bar.baz" (which IMHO would be quite
> >>> stupid also for size purposes)?
> >>>
> >>
> >> Yes, the latter ("foo->bar.baz") is closer to what the format does for
> >> CO-RE relocations!
> >>
> >>> That said, fix the format.
> >>>
> >>> Alternatively hand the CO-RE part its own string table (what's the fuss
> >>> with re-using the CTF string table if there's nothing to share ...)
> >>>
> >>
> >> BTF and .BTF.ext formats are specified already by implementations in the
> >> kernel, libbpf, and LLVM. For that matter, I should add BPF CO-RE to the
> >> mix and say that BPF CO-RE capability _and_ .BTF/.BTF.ext debug formats
> >> have been defined already by the BPF kernel developers/associated
> >> entities. At this time, we as GCC developers simply extending the BPF
> >> backend/BTF generation support in GCC, cannot fix the format. That ship
> >> has sailed.
> >
> > Hmm, well. How about emitting .BTF.ext.string from GCC and have the linker
> > merge the .BTF.ext.string section with the CTF string section then? You
> > can't
> > really say "the ship has sailed" if I read the CTF webpage - there seems to
> > be
> > many format changes planned.
> >
> > Well. Guess that was it from my side on the topic of ranting about the
> > not well thought out debug format ;)
> >
> > Richard.
>
> Hello Richard,
>
> As we clarified in this thread, BTF/CO-RE format cannot be changed. What
> are your thoughts on this patch set now ? Is this OK ?
Since the issue is intrinsic to BTF/CO-RE and not the actual target can we
do w/o a target hook by just gating on BTF_WITH_CORE as debug format
or so?
Richard.
> Thanks
> Indu
>
> >> Thanks for reviewing and voicing your concerns.
> >> Indu
> >>
> >>
> >>> Richard.
