On Fri, Apr 23, 2021 at 08:30:07AM +0800, Xi Ruoyao via Gcc-help wrote: > > > Position-independent code requires special support, and > > > therefore works only on certain machines. For the x86, GCC supports > > > PIC for System V but not for the Sun 386i. > > > Code > > > generated for the IBM RS/6000 is always position- > > > independent. > > > > So -fpic should not be specified on IBM RS/6000? Is it still a > > relevant architecture nowadays? It seems to be an old architecture > > which is not relevant nowadays. This seems to be some history text > > lingering on the manpage. Why not delete them from the manpage? > > The architecture of RS/6000 is PowerPC. PowerPC is *based* on the earlier POWER architecture (not the same thing as what is called Power Architecture now, which is PowerPC essentially). Most instructions are the same (in binary), but almost all mnemonics changed, and there were some more fundamental changes as well. > PowerPC is absolutely relevant today, Glad to hear other people think so :-) > and the code generated for other PowerPC CPUs are also always > postion-independent. A lot of PowerPC code is position-independent. The way most instructions work lends itself to that. For example, all "normal" branches and subroutine calls are PC-relative. But, there also are branch instructions that take absolute addresses (the AA bit in insns, used in "bla" for example), and load and store insns can also use absolute addressing. These can never be PIC, by definition. Furthermore, you can always write code that is not PIC, that requires to be run at some specific address. What is and isn't PIC code depends on what *exactly* you call PIC code. This is not always the same. For example, look at FDPIC, or at more generic schemes with multiple independently allocated segments (allocated at run time). And then there is -fPIC, which is a compiler flag for generating code suitable for shared libraries. Which is a bit *more* than just being "position independent" (it requires some specific code models, to make dynamic linking work). The flag name might not be ideal, but it is nice and short, there isn't too much confusion with it, and it is historical. Segher
