In my environment, cores are huge, so naturally we have them compressed all the time. It would be really *really* convenient to not have to decompress the core files and store them on disk (a process that can take several minutes) just to spend 10 seconds looking at a backtrace to go "a ha!". If GDB supported reading especially gzipped core files natively, it would be a big help.
You should be able to get that transparently at the filesystem level, with something like fuse's archivemount.
One (probably easy to solve) problem with something like fuse archivemount is, that it only mounts archives, so you have to create a tar.gz from it. Those file formats complicate things somewhat, and generally people do just want to compress the files (I do it with xz btw., which makes them factors smaller than gz) Another point is (and I stumbled over this report because I wanted such a feature too) that you often have to debug on systems where this is not possible. In a company you don't have the necessary priviliges to install the fuse stuff, your kernel and/or userspace tools are too old. And you have to debug on the system where the core file is, because you have no other system with the same .so files and other stuff installed. It might be on a customers machine where all you have is your statically linked gdb... It might not be desireable to pull dependencies of compression libraries in, but maybe gdb can support them via dlopen, and then support gz/bz2/xz/whatever if it is present.
Using fuse would just be a hack, native support inside gdb would be much more useful.
systemd lz4-compresses the coredumps. Teach gdb to open lz4 compressed coredumps, so that no unpacking is necessary. I use gdb 8.3.50.20190319-git .
I asked at https://github.com/systemd/systemd/issues/12237 to provide in systemd out-of-the-box uncompressing of coredumps, e.g. with archivemount.
For the systemd’o case it was suggested to use $(coredumpctl debug PID), I think this is sufficient.
Opening and Writing coredumps compressed would be really useful, even if opening it just means that there's an automated uncompress under $TMP and then the resulting file is opened as "normal" coredump.