Compressed debug information

Compressed debug information

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]

HI,

I have a question about compressed debug sections.  I think I am
getting compressed debug sections because a build of our product
with -gz=none (using GCC 12.1) results in larger artifacts than a
build without -gz=none.  Moreover, if I use ld.lld for the linker, where
I built LLVM without zlib support, it complains that the object files were
ELF_COMPRESSED and ld.lld could not handle them because LLVM
was built with zlib support.

Because of that I am under  the impression that the compressed debug
section object files fed into the linker result in compressed debug sections
in the final shared library or executable, provided the linker can handle
compressed debug sections.

But I don't know how to verify that the final debug section(s) in the
executables/shared libraries have debug information.  Google was not my
friend with respect to determining that.  I looked at readelf and
objdump options (from binutils 2.39) and didn't see an option for that. I
also looked at dwarfdump output but didn't see anything.

Any hints?

Thanks,

Tom

Re: Compressed debug information

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

Hi again,

On Sun, Mar 26, 2023 at 10:21 AM Tom Kacvinsky <tkacvins@gmail.com> wrote:

> HI,
>
> I have a question about compressed debug sections.  I think I am
> getting compressed debug sections because a build of our product
> with -gz=none (using GCC 12.1) results in larger artifacts than a
> build without -gz=none.  Moreover, if I use ld.lld for the linker, where
> I built LLVM without zlib support, it complains that the object files were
> ELF_COMPRESSED and ld.lld could not handle them because LLVM
> was built with zlib support.
>
> Because of that I am under  the impression that the compressed debug
> section object files fed into the linker result in compressed debug
> sections
> in the final shared library or executable, provided the linker can handle
> compressed debug sections.
>
> But I don't know how to verify that the final debug section(s) in the
> executables/shared libraries have debug information.  Google was not my
> friend with respect to determining that.  I looked at readelf and
> objdump options (from binutils 2.39) and didn't see an option for that. I
> also looked at dwarfdump output but didn't see anything.
>
> Any hints?
>
>
I'd like to retract this idiotic question of mine.  Turns out that no,
there was
no compressed debug data.  I compared -gz=none and against a build w/o
-gz=none and the sizes were the same.  Then I built with -gz=zlib and the
file sizes then changed.

So I found my answer by experimentation.  Now I am going to see what I
can do to get this information using tools like readelf or dwarfdump.

Tom

Re: Compressed debug information

[Fangrui Song]

On Sun, Mar 26, 2023 at 8:29 AM Tom Kacvinsky via Binutils
<binutils@sourceware.org> wrote:
>
> Hi again,
>
> On Sun, Mar 26, 2023 at 10:21 AM Tom Kacvinsky <tkacvins@gmail.com> wrote:
>
> > HI,
> >
> > I have a question about compressed debug sections.  I think I am
> > getting compressed debug sections because a build of our product
> > with -gz=none (using GCC 12.1) results in larger artifacts than a
> > build without -gz=none.  Moreover, if I use ld.lld for the linker, where
> > I built LLVM without zlib support, it complains that the object files were
> > ELF_COMPRESSED and ld.lld could not handle them because LLVM
> > was built with zlib support.
> >
> > Because of that I am under  the impression that the compressed debug
> > section object files fed into the linker result in compressed debug
> > sections
> > in the final shared library or executable, provided the linker can handle
> > compressed debug sections.
> >
> > But I don't know how to verify that the final debug section(s) in the
> > executables/shared libraries have debug information.  Google was not my
> > friend with respect to determining that.  I looked at readelf and
> > objdump options (from binutils 2.39) and didn't see an option for that. I
> > also looked at dwarfdump output but didn't see anything.
> >
> > Any hints?
> >
> >
> I'd like to retract this idiotic question of mine.  Turns out that no,
> there was
> no compressed debug data.  I compared -gz=none and against a build w/o
> -gz=none and the sizes were the same.  Then I built with -gz=zlib and the
> file sizes then changed.
>
> So I found my answer by experimentation.  Now I am going to see what I
> can do to get this information using tools like readelf or dwarfdump.
>
> Tom

Hi, Tom, you can use readelf -S or readelf -t to check whether an
object file has compressed debug sections.

% readelf -S a.o
...
Section Headers:
  [Nr] Name              Type            Address          Off    Size
 ES Flg Lk Inf Al
...
  [ 5] .debug_abbrev     PROGBITS        0000000000000000 000080
000087 00   C  0   0  8
% readelf -t a.o
...
Section Headers:
  [Nr] Name
       Type            Address          Off    Size   ES   Lk Inf Al
       Flags
...
  [ 5] .debug_abbrev
       PROGBITS        0000000000000000 000080 000087 00   0   0  8
       [0000000000000800]: COMPRESSED
       ZLIB, 0000000000000093, 1

I have just added the information to my blog post:
https://maskray.me/blog/2022-01-23-compressed-debug-sections