Date: Wed, 23 Feb 2022 19:14:39 -0500 From: Mark Johnston <markj@freebsd.org> To: freebsd-hackers@freebsd.org Cc: domagoj.stolfa@gmail.com Subject: patches for CTFv3 Message-ID: <YhbN77TGPuEpNfzl@nuc>
next in thread | raw e-mail | index | archive | help
Hi, I've finished a first draft of some patches which extend the CTF (compact C type format) definitions, making them a bit less compact but increasing the limit on the number of permitted C types, as an amd64 GENERIC kernel has been close to the limit for a while now, causing frustrating dtrace failures. The new format is CTFv3, compatible at least in principle with binutils libctf. The patches add support for v3 to various CTF producers and consumers. The one which adds v3 definitions is https://reviews.freebsd.org/D34360 and the rest can be viewed under the "stack" tab. In particular, the limit on the number of representable types grows from 2^{15} to 2^{31} - 1, hopefully enough to last for a while. The kernel's CTF section grows somewhat. The (zlib-compressed) on-disk size for an amd64 kernel increases from 1.02MB to 1.08MB, and the uncompressed size increases from 2.50MB to 3.31MB. In other words, the impact is hopefully unnoticeable if one's not using dtrace, and otherwise I believe the increase in memory usage isn't prohibitive. With the patches, libctf and ctfdump handle both v2 and v3. ctfconvert is changed to always emit v3, and ctfmerge can merge v2 and v3 containers, always creating a v3 container. The kernel works with v2 or v3, i.e., there should be no problem using dtrace with an updated kernel and an old version of the CTF toolchain. If it really becomes useful to be able to request v2 output from ctfconvert and ctfmerge, it could be added, but I don't have a reason to implement it yet. Any feedback on the changes would be appreciated. Thanks, -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YhbN77TGPuEpNfzl>