Messages in this thread | | | Date | Wed, 6 Jan 2021 15:26:18 -0800 | From | Kees Cook <> | Subject | Re: [PATCH v2 mips-next 2/4] MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS |
| |
On Wed, Jan 06, 2021 at 10:36:38PM +0000, Alexander Lobakin wrote: > From: Kees Cook <keescook@chromium.org> > Date: Wed, 6 Jan 2021 14:07:07 -0800 > > > On Wed, Jan 06, 2021 at 08:08:19PM +0000, Alexander Lobakin wrote: > >> Discard GNU attributes at link time as kernel doesn't use it at all. > >> Solves a dozen of the following ld warnings (one per every file): > >> > >> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' > >> from `arch/mips/kernel/head.o' being placed in section > >> `.gnu.attributes' > >> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' > >> from `init/main.o' being placed in section `.gnu.attributes' > >> > >> Misc: sort DISCARDS section entries alphabetically. > > > > Hmm, I wonder what is causing the appearance of .eh_frame? With help I > > tracked down all the causes of this on x86, arm, and arm64, so that's > > why it's not in the asm-generic DISCARDS section. I suspect this could > > be cleaned up for mips too? > > I could take a look and hunt it down. Could you please give some refs on > what were the causes and solutions for the mentioned architectures?
Sure! Here are the ones I could find again:
34b4a5c54c42 ("arm64/kernel: Remove needless Call Frame Information annotations") 6e0a66d10c5b ("arm64/build: Remove .eh_frame* sections due to unwind tables") d1c0272bc1c0 ("x86/boot/compressed: Remove, discard, or assert for unwanted sections")
> > Similarly for .gnu.attributes. What is generating that? (Or, more > > specifically, why is it both being generated AND discarded?) > > On my setup, GNU Attributes consist of MIPS FP type (soft) and > (if I'm correct) MIPS GNU Hash tables.
Ah, right, the soft-float markings sound correct to discard, IIUC.
> By the way. I've built the kernel with LLVM stack (and found several > subjects for more patches) and, besides '.got', also got a fistful > of '.data..compoundliteral*' symbols (drivers/mtd/nand/spi/, > net/ipv6/ etc). Where should they be placed (rodata, rwdata, ...) > or they are anomalies of some kind and should be fixed somehow?
Ah yeah, I've seen this before: https://lore.kernel.org/lkml/202010051345.2Q0cvqdM-lkp@intel.com/ https://lore.kernel.org/lkml/CAKwvOd=s53vUELe311VSjxt2_eQd+RGNCf__n+cV+R=PQ_CdXQ@mail.gmail.com/
And it looks like LTO trips over it too: https://lore.kernel.org/lkml/20201211184633.3213045-3-samitolvanen@google.com/
So I think the correct solution is to follow Sami's patch and add it to vmlinux.lds.h:
-#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX* +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral* ... -#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* -#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* +#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L* +#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral*
Can you include a patch for this in your series?
Thanks!
-- Kees Cook
| |