Question on why specific ELF relocations are supported for module loader

Question on why specific ELF relocations are supported for module loader

[Yifan Lu]

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?

Question on why specific ELF relocations are supported for module loader

[Ard Biesheuvel]

On 22 May 2015 at 08:46, Yifan Lu <yifanlu@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.

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@linaro.org> wrote:
> 
> On 22 May 2015 at 08:46, Yifan Lu <yifanlu@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.

Question on why specific ELF relocations are supported for module loader

[Russell King - ARM Linux]

Please wrap your message at or before column 72, so I don't have to do that
work for you in order to compose my reply.

On Fri, May 22, 2015 at 12:22:38AM -0700, Yifan Lu wrote:
> Is it even standards adherent that static relocation is used in an
> executable (rather than an object file)?

Which executable are you referring to?  The only executable is the
kernel binary itself, which is a fully-linked executable (which is
converted to a binary image.)  Modules are not executables, they
are (as Ard correctly pointed out) ELF objects.

You can't execute a module on its own: it requires to be linked to
its kernel in order to become an executable object.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.