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 ?
Thanks
Indu
Thanks for reviewing and voicing your concerns.
Indu
Richard.
