Messages in this thread | | | Date | Thu, 27 Jan 2022 12:27:04 +0000 | From | Mark Rutland <> | Subject | Re: [powerpc] ftrace warning kernel/trace/ftrace.c:2068 with code-patching selftests |
| |
On Thu, Jan 27, 2022 at 01:04:41PM +0100, Sven Schnelle wrote: > Mark Rutland <mark.rutland@arm.com> writes: > > >> Isn't x86 relocatable in some configurations (e.g. for KASLR)? > >> > >> I can't see how the sort works for those cases, because the mcount_loc entries > >> are absolute, and either: > >> > >> * The sorted entries will get overwritten by the unsorted relocation entries, > >> and won't be sorted. > >> > >> * The sorted entries won't get overwritten, but then the absolute address will > >> be wrong since they hadn't been relocated. > >> > >> How does that work? > > From what i've seen when looking into this ftrace sort problem x86 has a > a relocation tool, which is run before final linking: arch/x86/tools/relocs.c > This tools converts all the required relocations to three types: > > - 32 bit relocations > - 64 bit relocations > - inverse 32 bit relocations > > These are added to the end of the image. > > The decompressor then iterates over that array, and just adds/subtracts > the KASLR offset - see arch/x86/boot/compressed/misc.c, handle_relocations() > > So IMHO x86 never uses 'real' relocations during boot, and just > adds/subtracts. That's why the order stays the same, and the compile > time sort works.
Ah, so those non-ELF relocations for the mcount_loc table just mean "apply the KASLR offset here", which is equivalent for all entries.
That makes sense, thanks!
Mark.
| |