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@xxxxxxxxxxxxxxxxxxx> 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
