0

I know that object files(.o) are always relocatable,

what about .a and .so files?

linux
  • 1
  • 1
  • What makes you so sure about .o files? As far as I know they contain relocation information, in other words some addresses are only filled in at link time. I would say that calling this relocatable is incorrect. – Albert van der Horst Nov 23 '19 at 16:16

3 Answers3

3

A .a file is just an archive of other files. Typically those are .o files, to which you already know the answer. They don't have to be though - they don't have to be object code at all in fact - they can literally be any files you like.

A .so file has to be relocatable to work as it has to be able to be loaded at different addresses in different processes depending on what address is available at runtime.

TomH
  • 1,290
  • 7
  • 10
1

Let us start with what is the established definition of relocatable. A piece of code is relocatable, if it can be placed anywhere in memory without change and execute properly. So neither .o and .a files can be relocatable, because they are not pieces of code (!). A .o files contains a piece of code with accompagnying information and a .a files is a collection of whatever files, possibly .o.

Then, is the code contained in a .o relocatable? No, not in general, because it has to be souped up by a linker to fill in addresses using information that is supplied with the .o file. E.g. a sine is calculated using a polynomial evaluator that is in some other library only the linker knows about. So the call address of the polynomial evaluator must still be filled in; in other words, the code cannot be executed as such.

At last, the code in a .so file is relocatable, because this code is shared and can be executed by several processes at once. It would be inconvenient if all those processes had to place the code at the one address where it executes properly.

0

It might be a little late, but let me try:

  • *.o: object module, might be 'pic' or 'non-pic'
  • *.a: a collection of object modules
  • *.so: shared object/library, it has to be built from 'pic' object
  • 'pic' code: position-indendent code, it can be loaded at any position and be run with relocation.
  • 'non-pic' code: it has to be placed to a fix address; or it has to be relocated after loading into the memory; 'non-pic' object modules cannot be used when linking a shared object

Bonus: an executable doesn't have to be 'pic', but if it is, ASLR can be used when running it: https://en.wikipedia.org/wiki/Address_space_layout_randomization