[PATCH] ARM: decompressor: fix BSS size calculation for LLVM ld.lld

[Nick Desaulniers]

On Fri, Feb 5, 2021 at 10:11 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Fri, 5 Feb 2021 at 19:00, Nick Desaulniers <ndesaulniers at google.com> wrote:
> >
> > On Fri, Feb 5, 2021 at 12:52 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > >
> > > The LLVM ld.lld linker uses a different symbol type for __bss_start,
> > > resulting in the calculation of KBSS_SZ to be thrown off. Up until now,
> > > this has gone unnoticed as it only affects the appended DTB case, but
> > > pending changes for ARM in the way the decompressed kernel is cleaned
> > > from the caches has uncovered this problem.
> > >
> > > On a ld.lld build:
> > >
> > >   $ nm vmlinux |grep bss_
> > >   c1c22034 D __bss_start
> > >   c1c86e98 B __bss_stop
> > >
> > + Fangrui,
> > Fangrui, __bss_start looks like it's linker script defined by the
> > BSS_SECTION macro from include/asm-generic/vmlinux.lds.h:1160 being
> > used in arch/arm/kernel/vmlinux.lds.S:149.  Should these symbols be
> > placed in .bss? Might save a few bytes in the image, unless there's an
> > initial value that's encoded with them?
> >
>
> Not sure what you are asking here. These symbols just delineate .bss,
> they don't take up any space themselves.
>
> What seems to be happening is that the placement of __bss_start
> outside of the .sbss/.bss section declarations causes it to be
> annotated as residing in .data.

Perhaps a misunderstanding on my part on how symbols are represented
in ELF, but my understanding is:

$ cat foo.c
int foo;
int bar = 0;
int baz = 42;
$ cc -c foo.c
$ nm foo.o
0000000000000004 B bar
0000000000000000 D baz
0000000000000000 B foo
$ ls -l foo.o
-rw-r----- 1 ndesaulniers primarygroup 1016 Feb  5 10:47 foo.o

$ cat bar.c
int foo;
int bar = 0;
int baz = 0; // changed from foo.c
$ cc -c bar.o
$ nm bar.o
0000000000000004 B bar
0000000000000008 B baz
0000000000000000 B foo
$ ls -l bar.o
-rw-r----- 1 ndesaulniers primarygroup 1008 Feb  5 10:48 bar.o
# ^ smaller object file

That if a symbol's value was an address within .bss, then there was no
additional space reserved in an ELF object since the initial value for
all such symbols in the section can memset to 0 by the loader.  But if
a symbol's value was an address in .data, that initial value must
occupy space in the object file.  Perhaps that's not the case though
for linker defined symbols, since I'm not sure what data/initial value
they would correspond to besides the Elf{32|64}_Sym's value in the
symbol table?  (I should go reread the relevant section from Expert C
Programming: Deep C Secrets, or finish reading Linkers and Loaders).
-- 
Thanks,
~Nick Desaulniers