On 2020-05-12, Nick Desaulniers wrote:
On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> ><nick.desaulniers@xxxxxxxxx> wrote:
> >>
> >> As debug information gets larger and larger, it helps significantly save
> >> the size of vmlinux images to compress the information in the debug
> >> information sections. Note: this debug info is typically split off from
> >> the final compressed kernel image, which is why vmlinux is what's used
> >> in conjunction with GDB. Minimizing the debug info size should have no
> >> impact on boot times, or final compressed kernel image size.
> >>
Nick,
I am OK with this patch.
Fangrui provided the minimal requirement for
--compress-debug-sections=zlib
Is it worth recording in the help text?
Do you want to send v2?
Yes I'd like to record that information. I can also record Sedat's
Tested-by tag. Thank you for testing Sedat.
I don't know what "linux-image-dbg file" are, or why they would be
bigger. The size of the debug info is the primary concern with this
config. It sounds like however that file is created might be
problematic.
Fangrui, I wasn't able to easily find what version of binutils first
added support. Can you please teach me how to fish?
I actually downloaded https://ftp.gnu.org/gnu/binutils/ archives and
located the sources... I think an easier way is:
% cd binutils-gdb
% git show binutils-2_26:./gas/as.c | grep compress-debug-sections
--compress-debug-sections[={none|zlib|zlib-gnu|zlib-gabi}]\n\
...
GNU as 2.25 only supports --compress-debug-sections which means "zlib-gnu" in
newer versions.
Similarly, for GNU ld:
% git show binutils-2_26:./ld/lexsup.c | grep compress-debug-sections
--compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi]\n\
(I have spent a lot of time investigating GNU ld's behavior :)
Another question I had for Fangrui is, if the linker can compress
these sections, shouldn't we just have the linker do it, not the the
compiler and assembler? IIUC the debug info can contain relocations,
so the linker would have to decompress these, perform relocations,
then recompress these? I guess having the compiler and assembler
compress the debug info as well would minimize the size of the .o
files on disk.
The linker will decompress debug info unconditionally. Because
input .debug_info sections need to be concatenated to form the output
.debug_info . Whether the output .debug_info is compressed is controlled
by the linker option --compress-debug-sections=zlib, which is not
affected by the compression state of object files.
Both GNU as and GNU ld name the option --compress-debug-sections=zlib.
In a compiler driver context, an unfamiliar user may find
-Wa,--compress-debug-sections=zlib -Wl,--compress-debug-sections=zlib
confusing:/
Otherwise I should add this flag to the assembler invocation, too, in
v2. Thoughts?
Compressing object files along with the linked output should be fine. It
can save disk space. (It'd be great if you paste the comparison
with and w/o object files compressed)
Feel free to add:
Reviewed-by: Fangrui Song <maskray@xxxxxxxxxx>
I have a patch series that enables dwarf5 support in the kernel that
I'm working up to. I wanted to send this first. Both roughly reduce
the debug info size by 20% each, though I haven't measured them
together, yet. Requires ToT binutils because there have been many
fixes from reports of mine recently.
This will be awesome! I also heard that enabling DWARF v5 for our object
files can easily make debug info size smaller by 20%. Glad that the
kernel can benefit it as well:)
