how to add -fPIC support ?

[William Tambe]

Are there any machine-description constructs specific to -fPIC ?
if yes, where can I find their documentation ?

On Sun, Feb 23, 2020 at 6:58 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> 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