Re: Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain

Yeah, that checks out then. (you can also confirm that SHF_COMPRESSED
is not used by readelf -S or llvm-readelf -S and checking for the "C"
value in the Flags column)

& yeah, that does seem like quite a bit of RAM usage for a relatively
small amount of debug info. Though I'm not a regular/frequent gdb
developer, so I don't have any particular insight there - if no one
else chimes in, might be worth running valgrind --tool=massif to get a
memory profile, might point to what part of gdb is using all the RAM.

On Sun, Apr 18, 2021 at 1:16 AM R. Diez <[email protected]> wrote:
>
>
> >> The debug information is not compressed.
> >
> > How are you determining that ^ ?
> >
> > (I ask, because historically compressed debug info was opt-in and used
> > a section name mangling (.zdebug_*) to notate compressed debug
> > sections - but recent versions of GCC have started compressing by
> > default and using an ELF section flag (SHF_COMPRESSED) without section
> > name mangling (so dumping section names would not be enough to
> > determine whether compressed debug info was used)
>
>
> I do not know about SHF_COMPRESSED.
>
> I checked with:
>
> $ ./arm-none-eabi-ld --help
>
> [...]
> --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi]
>      Compress DWARF debug sections using zlib
>      Default: none
> [...]
>
>
> I did not quite trust the "Default: none" statement, so I tested in the past by passing the following flag:
>
> -Wl,--compress-debug-sections=zlib
>
> And the resulting elf file was less than half the size.
>
> That is how I assume that the debug information is not being compressed.
>
> I am not compressing because for such a little project it is not worth it.
>
> Regards,
>    rdiez