Mark Rutland <mark.rutl...@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. /Sven
