Doesn't PIC mean no relocations?

1
votes

I'm building an ELF SO for bada on ARM using GCC. The compiler options include -fpic. Yet in the built file, when I do readelf -r, there's a whole lot of relocation records, of following types:

  • R_ARM_RELATIVE
  • R_ARM_REL32
  • R_ARM_ABS32
  • R_ARM_GLOB_DAT
  • R_ARM_JUMP_SLOT

What am I misunderstanding here?

EDIT: from what I can see, the PIC implementation in the compiler doesn't use GOT. Instead, they use PC-relative addressing with stored constants being offsets from point of use to the symbol address; that's resolved by the linker. Like this, to read a global variable:

    ldr r12, OffsetToVar
PointOfUse:
    ldr r0, [r12, pc] 
# r0 now has the value of MyVar

#...

# At function's end...
OffsetToVar:
    .long MyVar-PointOfUse-8
# Compiler can't resolve this, since it doesn't know
# the address of MyVar, but linker can

Similar idea for cross-module function calls. When a project mixes ARM and Thumb code though, the latter may misfire. But I've worked around that.

1
gccassemblyarmelf
Just a guess, do you access global data? If so the code may be a PIC, but the data is still bound to a possibly changing address? - Alexis Wilke
PIC means Position Independent Code. Instructions are chosen so that that chunk of code will execute properly even if loaded at an address space it was not linked for. - old_timer
I will take a guess at what you want (but not an answer to the question). See -fixed-REG, use -msingle-pic-base, and -mpic-register where your scheduler must set r9 to point to global data. So for instance, without an MMU you can run multiple code instances and replace r9 as a pointer to globals for that task/thread/process. This is a mechanism to avoid data relocation. Also, it is common for the compiler/linker to emit relocations that are normally not needed. - artless noise

1 Answers

5
votes

Doesn't PIC mean no relocations?

No, it does not.

It just means no relocations against .text section (so the .text can be shared between multiple processes).