On Thu, 27 Jan 2022 at 13:20, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Thu, Jan 27, 2022 at 01:03:34PM +0100, Ard Biesheuvel wrote: > > On Thu, 27 Jan 2022 at 12:47, Mark Rutland <mark.rutl...@arm.com> wrote: > > > > > > [adding LKML so this is easier for others to find] > > > > > > If anyone wants to follow the thread from the start, it's at: > > > > > > > > > https://lore.kernel.org/linuxppc-dev/944d10da-8200-4ba9-8d0a-3bed9aa99...@linux.ibm.com/ > > > > > > Ard, I was under the impression that the 32-bit arm kernel was (virtually) > > > relocatable, but I couldn't spot where, and suspect I'm mistaken. Do you > > > know > > > whether it currently does any boot-time dynamic relocation? > > > > No, it does not. > > Thanks for comfirming! > > So 32-bit arm should be able to opt into the build-time sort as-is. > > > > Steve asked for a bit more detail on IRC, so the below is an attempt to > > > explain > > > what's actually going on here. > > > > > > The short answer is that relocatable kernels (e.g. those with KASLR > > > support) > > > need to handle the kernel being loaded at (somewhat) arbitrary virtual > > > addresses. Even where code can be position-independent, any pointers in > > > the > > > kernel image (e.g. the contents of the mcount_loc table) need to be > > > updated to > > > account for the specific VA the kernel was loaded at -- arch code does > > > this > > > early at boot time by applying dynamic (ELF) relocations. > > > > These architectures use place-relative extables for the same reason: > > place relative references are resolved at build time rather than at > > runtime during relocation, making a build time sort feasible. > > > > arch/alpha/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/arm64/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/ia64/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/parisc/include/asm/uaccess.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/powerpc/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/riscv/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/s390/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > arch/x86/include/asm/extable.h:#define ARCH_HAS_RELATIVE_EXTABLE > > > > Note that the swap routine becomes something like the below, given > > that the relative references need to be fixed up after the entry > > changes place in the sorted list. > > > > static void swap_ex(void *a, void *b, int size) > > { > > struct exception_table_entry *x = a, *y = b, tmp; > > int delta = b - a; > > > > tmp = *x; > > x->insn = y->insn + delta; > > y->insn = tmp.insn - delta; > > ... > > } > > > > As a bonus, the resulting footprint of the table in the image is > > reduced by 8x, given that every 8 byte pointer has an accompanying 24 > > byte RELA record, so we go from 32 bytes to 4 bytes for every call to > > __gnu_mcount_mc. > > Absolutely -- it'd be great if we could do that for the callsite locations; > the > difficulty is that the entries are generated by the compiler itself, so we'd > either need some build/link time processing to convert each absolute 64-bit > value to a relative 32-bit offset, or new compiler options to generate those > as > relative offsets from the outset. >
Don't we use scripts/recordmcount.pl for that?
