[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <30b01c65-12f2-4ee0-81d5-c7a2da2c36b4@app.fastmail.com>
Date: Wed, 21 Feb 2024 16:51:26 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Yuntao Liu" <liuyuntao12@...wei.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc: "Russell King" <linux@...linux.org.uk>, "Andrew Davis" <afd@...com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
"Geert Uytterhoeven" <geert+renesas@...der.be>,
"Jonathan Corbet" <corbet@....net>, "Mike Rapoport" <rppt@...nel.org>,
"Eric DeVolder" <eric.devolder@...cle.com>, "Rob Herring" <robh@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Linus Walleij" <linus.walleij@...aro.org>
Subject: Re: [PATCH -next] arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Tue, Feb 20, 2024, at 10:53, liuyuntao (F) wrote:
> 在 2024/2/20 16:40, Arnd Bergmann 写道:
>> On Tue, Feb 20, 2024, at 09:15, Yuntao Liu wrote:
> #
> # ARM discards the .data section because it disallows r/w data in the
> # decompressor. So move our .data to .data.efistub and .bss to .bss.efistub,
> # which are preserved explicitly by the decompressor linker script.
> #
> STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \
> --rename-section .bss=.bss.efistub,load,alloc
>
> ---
>
> I think that .data.efistub represents the entire .data section, the same
> applies to .bss as well,
>
> so i move all .data and .bss into the stub here.
>
Ok, I see.
>>
>> I guess this prevents discarding any function that has a reference
>> from pv_table or ex_table, even if there are no other references,
>> right?
>
> Indeed so, if not keep ex_table, the compilation process will result in
>
> an error:
>
> no __ex_table in file: vmlinux
>
> Failed to sort kernel tables
Sure, and without the ex_table contents, it would not be able
to recover from a failed uaccess either.
> and if not keep pv_table, It can be compiled successfully, but the QEMU
> boots will fail.
Right. The pv_table isn't technically necessary since it can
be disabled. I think it was originally introduced in order
to avoid performance regressions when we introduced multiplatform
kernels that can run at arbitrary physical addresses rather than
having it as a build-time constant.
I don't know how much difference that actually makes for performance,
so turning it into a normal runtime lookup may or may not be
a good compromise when building with HAVE_LD_DEAD_CODE_DATA_ELIMINATION.
I have given your patch some build testing with random
configurations in my build setup and it seems to work
fine with gcc/binutils, but unfortunately I came across
a link failure using clang/lld:
ld.lld: error: ./arch/arm/kernel/vmlinux.lds:35: ( expected, but got }
>>> __vectors_lma = .; OVERLAY 0xffff0000 : AT(__vectors_lma) { .vectors { KEEP(*(.vectors)) } .vectors.bhb.loop8 { KEEP(*(.vectors.bhb.loop8)) } .vectors.bhb.bpiall { KEEP(*(.vectors.bhb.bpiall)) } } __vectors_start = LOADADDR(.vectors); __vectors_end = LOADADDR(.vectors) + SIZEOF(.vectors); __vectors_bhb_loop8_start = LOADADDR(.vectors.bhb.loop8); __vectors_bhb_loop8_end = LOADADDR(.vectors.bhb.loop8) + SIZEOF(.vectors.bhb.loop8); __vectors_bhb_bpiall_start = LOADADDR(.vectors.bhb.bpiall); __vectors_bhb_bpiall_end = LOADADDR(.vectors.bhb.bpiall) + SIZEOF(.vectors.bhb.bpiall); . = __vectors_lma + SIZEOF(.vectors) + SIZEOF(vectors.bhb.loop8) + SIZEOF(.vectors.bhb.bpiall); __stubs_lma = .; .stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) { *(.stubs) } __stubs_start = LOADADDR(.stubs); __stubs_end = LOADADDR(.stubs) + SIZEOF(.stubs); . = __stubs_lma + SIZEOF(.stubs); PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
>>> ^
I don't immediately see what the problem is here, I hope you
can address it before you send a v2.
Arnd
Powered by blists - more mailing lists