0

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

what about .a and .so files?

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. Nov 23, 2019 at 16:16

3 Answers 3

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.

4
  • So .a file is not ELF format,why can nm still deal with it?
    – linux
    Jul 13, 2011 at 14:06
  • Because it has been taught how to read them...
    – TomH
    Jul 13, 2011 at 14:43
  • What format is ar using?
    – linux
    Jul 13, 2011 at 15:34
  • 1
    The ar archive format ;-)
    – TomH
    Jul 13, 2011 at 15:52
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .