Question

I have been reading John R. Levine’s Linkers and Loaders and I read that the properties of an object file will include one or more of the following.

1. file should be linkable
2. file should be loadable
3. file should be executable

Now, considering this example:

#include<stdio.h>
int main() {
  printf("testing\n");
  return 0;
}

Which I would compile and link with:

$ gcc -c t.c
$ gcc -o t t.o

I tried inspecting t.o using objdump and its type shows up as REL. What all properties does t.o satisfy? I believe that its linkable, non-executable. I would have believed that its not loadable(unless you create an .so file from the .o file); however the type REL means that its supposed to be relocated, and relocation would occur only in the context of loading, so I’m having a confusion here.
My doubts summarized :-

1. Are “.o” files loadable?
2. Reading resources regarding the sections present in a “.o”, “.so” file – differences etc?

Answer 1

An object file (i.e., a file with the .o extension) is not loadable. This is because it lacks critical information about how to resolve all the symbols within it: in this case, the println symbol in particular would need additional information. (C compilers do not bind library identities into the object files they create, which is occasionally even useful.)

When you link the object file into a shared library (.so), you are adding that binding. Typically, you’re also grouping a number of object files together and resolving references between them (plus a few more esoteric things). That then makes the result possible to load, since the loader can then just do resolution of references and loading of dependencies that it doesn’t already know about.

Going from there to executable is typically just a matter of adding on the OS-defined program bootstrap. This is a small piece of code that the OS will start the program running by calling, and it typically works by loading the rest of the program and dependencies and then calling main() with information about the arguments. (It’s also responsible for exiting cleanly if main returns.)