Question on why specific ELF relocations are supported for module loader

[Yifan Lu]

Is it even standards adherent that static relocation is used in an executable (rather than an object file)? Is there anything is GCC that will ensure that only these kinds of relocations are generated? I'm designing a simple ARM system that loads ELFs and I would rather not support all 130 relocations so this Linux module loader is a good model.
> On May 22, 2015, at 12:08 AM, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> 
> On 22 May 2015 at 08:46, Yifan Lu <yifanlu at stanford.edu> wrote:
>> I'm referring to linux/arch/arm/kernel/module.c. It seems to be an arbitrary subset of ARM ELF relocations. (The manual lists about 130 types of relocations.) Is it because GCC only outputs these types? Or is there another reason? Also, isn't static relocations only used for static linking?
>> 
> 
> Under the configuration that is used to compile the kernel, only a
> small subset of those relocations will ever be emitted by GCC. For
> instance, since we are building without -fpic, many of the GOT and PLT
> related ones will just never occur. And, since modules are not shared
> libraries, but just partially linked object files, the runtime linking
> that occurs actually resembles static linking more than it resembles
> dynamic linking. (There is no support for things like lazy resolution
> of jump targets or symbol preemption that the ELF standard defines.)
> Also, while text relocations are typically avoided in userland since
> they defeat sharing of code pages, this is not a problem in the
> kernel.