BTF-capable libctf (CTFv4) and BTF-deduplicating ld, heads-up and a few questions
Nick Alcock
nick.alcock@oracle.com
Fri Apr 25 21:40:11 GMT 2025
So a huge revision of CTF has been underway for a few months, more or
less exactly as described in my talk at Cauldron last year:
https://sourceware.org/binutils/wiki/CTF/Todo/CTFv4. This will make CTF
into a BTF superset and let libctf read, write, and deduplicate BTF as
well as CTF (and, with luck and in time, let BTF tools read CTF too,
maybe without needing to change them at all).
We're finally getting to the stage where this works well enough that I
think working in public on better-formed git branches rather than giant
stream-of-consciousness code dumps is starting to seem sensible, so that
at least it's clear to people what we're working on and what state it's
in. (It's definitely not at the stage of being ready for upstreaming
yet! See the TODO above.)
I've been working on the users/nalcock/road-to-ctfv4 branch in
binutils-gdb git, but maybe this should move to a feature branch of some
sort rather than a per-user branch? I'm not sure if feature branches
that aren't per-user branches are things binutils git does at all.
Would people mind if I started sending git commit mails when I made
nontrivial commits to that branch, so that at least people can see
what's happening? Or would people prefer me not to do so, or to
send mails somewhere else, or something?
At least I'd rather stop working in near-total silence! Everyone working
on this project would much rather work in public than on company-
internal lists like we have been before now: would people mind if we
started doing that on binutils@ (and gcc-patches@), or should we do it
on a new list? It's probably only a few mails a week now the most insane
pulse of development is dying down, so I hope adding to the traffic on
the existing lists is OK.
More information about the Binutils
mailing list