Hi, Changing subject because this has nothing to do with that Change Proposal anymore. On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote: > However, I think it's perfectly valid to discuss zstd if folks wanted to > change the compression scheme for debug sections. In fact, I'd claim > sticking with zlib, gzip, bzip2, xz, 7z, etc is unwise. The world has > moved and zstd seems like the place we should be. In fact, we use it > for various things within GCC already. Personally I must admit that I am not really a fan of using ELF section/file compression. It makes it impossible to simply mmap the data in or to quickly read just a tiny bit because you first have to decompress (and allocate new memory) for it. IMHO .debug files are no different from other ELF files for which we would also not do this. We can just use rpm package compression to reduce the distro distribution size, but we should not (re)compress the install/on-disk files. That will just mean programs will create an extra cache of uncompressed files they need to consult frequently. But if you are going to do it, then it does make sense to use the most efficient algorithm there is. If you are going to experiment with this there are two ways to go about it. First you can use full file compression. That is actually already (almost transparently) supported for tools based on elfutils libdw when using the dwfl functions. For example eu-readelf (and some other eu- tools) can be run on any compressed file directly (the version in rawhide also supports zstd because the vmlinuz file now uses that). You would have to convince other DWARF consumers to do the same. And decide for those that use .gnu_debuglink instead of build-id lookups (or when build-id lookup fails) whether the filenames should include the compression extension like .zst or if a consumer is responsible for trying all (?) known compression extensions when resolving the .debug file. Secondly you can use ELF section compression. The ELF spec leaves room for adding new compression algorithms. The Chdr struct(s) contain a ch_type which describes the algorithm. Currently only one is specified, but there is a lot of room for expansion: /* Legal values for ch_type (compression algorithm). */ #define ELFCOMPRESS_ZLIB 1 /* ZLIB/DEFLATE algorithm. */ #define ELFCOMPRESS_LOOS 0x60000000 /* Start of OS-specific. */ #define ELFCOMPRESS_HIOS 0x6fffffff /* End of OS-specific. */ #define ELFCOMPRESS_LOPROC 0x70000000 /* Start of processor-specific. */ #define ELFCOMPRESS_HIPROC 0x7fffffff /* End of processor-specific. */ So you could propose something on gnu-gabi@xxxxxxxxxxxxxx for a GNU extension or at generic-abi@xxxxxxxxxxxxxxxx for a generic ELF one. And then get the ELF processing tools to adopt the new compression type. Cheers, Mark _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
