On Sun, Feb 23, 2020 at 10:05:16AM +0100, Florian Weimer wrote:
> * William Tambe:
>
> > What needs to be done to support -fPIC ?
> >
> > Is there a commit that describe what needs to be done to support
> > -fPIC ?
>
> This is entirely target-specific. Some targets are always PIC.
Not really, no.
'-fpic'
Generate position-independent code (PIC) suitable for use in a
shared library, if supported for the target machine. Such code
accesses all constant addresses through a global offset table
(GOT).
'-fPIC'
If supported for the target machine, emit position-independent
code, suitable for dynamic linking and avoiding any limit on the
size of the global offset table.
Some processor architectures do not (normally) use absolute addresses,
or only via a GP or similar. Sure. But a) you *can* create code that
depends on the address it runs at, even then; b) you can generate code
that isn't in "normally"; and c) -fpic has the additional constraint
that it isn't just position-independent code, but also suitable for
use in a shared library, and -fPIC code also typically has to assume
that any "external" object or code can be anywhere in the address
space.
And yes, you will encounter at least one of a), b) and c) on most
ports.
Both -fpic and -fPIC enable specific programming models for shared
libraries, following some specific ABI. Often, non-fpic code is quite
a bit more efficient than fpic code, even if both are position-
independent.
As a very simple example, many targets have a "small data" section,
pointed to by some special base pointer. Often fpic code cannot use
that section (it would have to set up the base pointer for itself,
giving overhead on all calls, many ABIs choose not to).
Segher
