[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z5Epcb+GnqFegstq@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
Date: Wed, 22 Jan 2025 18:22:57 +0100
From: Alexander Gordeev <agordeev@...ux.ibm.com>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
Ard Biesheuvel <ardb@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
Ron Economos <re@...z.net>
Subject: Re: [PATCH v3] kbuild: Strip runtime const RELA sections correctly
On Wed, Jan 22, 2025 at 05:49:53PM +0100, Alexander Gordeev wrote:
> On Mon, Jan 13, 2025 at 04:53:07PM +0100, Ard Biesheuvel wrote:
>
> Hi Ard,
>
> > Due to the fact that runtime const ELF sections are named without a
> > leading period or double underscore, the RSTRIP logic that removes the
> > static RELA sections from vmlinux fails to identify them. This results
> > in a situation like below, where some sections that were supposed to get
> > removed are left behind.
> >
> > [Nr] Name Type Address Off Size ES Flg Lk Inf Al
> >
> > [58] runtime_shift_d_hash_shift PROGBITS ffffffff83500f50 2900f50 000014 00 A 0 0 1
> > [59] .relaruntime_shift_d_hash_shift RELA 0000000000000000 55b6f00 000078 18 I 70 58 8
> > [60] runtime_ptr_dentry_hashtable PROGBITS ffffffff83500f68 2900f68 000014 00 A 0 0 1
> > [61] .relaruntime_ptr_dentry_hashtable RELA 0000000000000000 55b6f78 000078 18 I 70 60 8
> > [62] runtime_ptr_USER_PTR_MAX PROGBITS ffffffff83500f80 2900f80 000238 00 A 0 0 1
> > [63] .relaruntime_ptr_USER_PTR_MAX RELA 0000000000000000 55b6ff0 000d50 18 I 70 62 8
> >
> > So tweak the match expression to strip all sections starting with .rel.
> > While at it, consolidate the logic used by RISC-V, s390 and x86 into a
> > single shared Makefile library command.
>
> On s390 this is before:
>
> [32] .relaruntime[...] RELA 0000000000000000 13b3fe20
> [34] .relaruntime[...] RELA 0000000000000000 13b3fe98
>
> This is after:
>
> [ 2] .rela.text RELA 0000000000000000 13b3fe20
...
> [73] .rela.debug_[...] RELA 0000000000000000 298eb5a8
Sorry, I checked the wrong version. It works as expected.
Tested-by: Alexander Gordeev <agordeev@...ux.ibm.com>
Powered by blists - more mailing lists