Re: [PATCH] export.h: reduce __ksymtab_strings string duplication by using "MS" section flags

From: Rasmus Villemoes
Date: Thu Nov 21 2019 - 05:51:56 EST


On 20/11/2019 15.51, Jessica Yu wrote:
>
> We can alleviate this situation by utilizing the SHF_MERGE and
> SHF_STRING section flags. SHF_MERGE|SHF_STRING indicate to the linker
> that the data in the section are null-terminated strings

[pet peeve: nul, not null.]

> As of v5.4-rc5, the following statistics were gathered with x86
> defconfig with approximately 10.7k exported symbols.
>
> Size of __ksymtab_strings in vmlinux:
> -------------------------------------
> v5.4-rc5: 213834 bytes
> v5.4-rc5 with commit c3a6cf19e695: 224455 bytes
> v5.4-rc5 with this patch: 205759 bytes
>
> So, we already see memory savings of ~8kB compared to vanilla -rc5 and
> savings of nearly 18.7kB compared to -rc5 with commit c3a6cf19e695 on top.

Yippee :) Thanks for picking up the ball and sending this.

> /*
> - * note on .section use: @progbits vs %progbits nastiness doesn't matter,
> - * since we immediately emit into those sections anyway.
> + * note on .section use: we specify @progbits vs %progbits since usage of
> + * "M" (SHF_MERGE) section flag requires it.
> */
> +
> +#ifdef CONFIG_ARM
> +#define ARCH_PROGBITS %progbits
> +#else
> +#define ARCH_PROGBITS @progbits
> +#endif

Did you figure out a way to determine if ARM is the only odd one? I was
just going by gas' documentation which mentions ARM as an example, but
doesn't really provide a way to know what each arch uses. I suppose 0day
will tell us shortly.

If we want to avoid arch-ifdefs in these headers (and that could become
unwieldy if ARM is not the only one) I think one could add a
asm-generic/progbits.h, add progbits.h to mandatory-y in
include/asm-generic/Kbuild, and then just provide a progbits.h on ARM
(and the other exceptions) - then I think the kbuild logic automatically
makes "#include <asm/progbits.h>" pick up the right one. And the header
could define ARCH_PROGBITS with or without the double quotes depending
on __ASSEMBLY__.

OTOH, adding a whole new header just for this may be overkill.

Rasmus