Re: New ch_type value ELFCOMPRESS_ZSTD?

[Nick Alcock <nick.alcock@oracle.com>]

On 27 Jun 2022, Fangrui Song stated:

> I created https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new
> ch_type value: ELFCOMPRESS_ZSTD") after I saw that on LLVM side, Cole Kissane
> proposes that we add Zstandard as new compression method (mainly for .debug*
> sections, but also for some LLVM internal things)
> https://discourse.llvm.org/t/rfc-zstandard-as-a-second-compression-method-to-llvm/63399

The next CTF format will be compressed with zstd too (if available),
fwiw. It's pretty obviously the right thing to go with these days for
anything but specialized use cases. So (though my opinion counts for
nothing) I think this is an excellent direction to go in.

(Of course, if zstd isn't folded into the binutils source tree like zlib
is, we have the interesting problem of what to do if it's not available
at build time. If zstd compression is optional, and not available in the
existing binutils, and gdb or objdump or something needs to read a
zstd-compressed debug section, what do we do? Error out? Whatever it is
we end up doing, I'll make libctf do the same thing in the same
situation.

Pointless detail: this will hardly ever impair use of things like ld
that must keep working because ld inputs are usually compiler output,
and the CTF in there is entirely uncompressed and undeduplicated. Only
using ld -r outputs as inputs to ld would be affected, and that's a rare
use case that is usually done as part of the same build process on the
same machine, and that use case would *also* keep working whether zstd
was available or not. The only case that might be impacted is users like
GDB being asked to read zstd-compressed sections when GDB was not
compiled with zstd support, and that's the same problem we'd have if the
same binary contained DWARF debuginfo and the same GDB were asked to
read it.)

-- 
NULL && (void)