This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] -fpie/-fPIE/-pie GCC support

On Mon, Jun 02, 2003 at 09:16:20PM +0100, Joseph S. Myers wrote:
> On Mon, 2 Jun 2003, Jakub Jelinek wrote:
> > This patch is the GCC side of Position Independent Executable support
> > which has been commited this week to binutils trunk.
> > The patch adds -pie option which is for linking, similarly to -shared.
> > This may select different crt files etc. and pass appropriate options
> > down to the linker.
> Where is the rationale / documentation for when PIE code is useful?  Is
> this something that is deliberately not added to the manual because if
> it's useful to you then you'll already understand it and why it's useful?

The manual does not talk about why shared libraries are useful either.
Position Independent Executables are useful for security exposed binaries
(such as networking daemons etc.) to make various exploits slightly harder.
Normal binaries are always linked at a specific address, so if you know you
are attacking distribution foobar-2.4, you can assume certain functions
will be at certain addresses, similarly to .plt slots through which you can
get even to shared library functions which can have randomized addresses.
Position Independent Executables can be started at any address, which in
some environments can be chosen by the kernel each time the program is run
to a random address, or can be prelink(8)ed to a certain raondom address,
such that it is fixed on a particular host but likely different
on different hosts.

> > or not). ATM the difference is in binds_local - like in non-fpic code
> > GCC can assume any non-common object defined in the same module, even if
> > not static, will be in the same binary (which means GOT relative accesses
> > to such variables, ability to inline non-static functions at -O3, etc.).
> There ought then to be testcases (that with PIC the compiler assumes
> functions can be overridden, with PIE it doesn't).

Will add them ASAP.

> You change many specs to define __PIC__ and __pic__ for PIE as well.  I
> can't find documentation of these macros: is the previously intended
> definition (that existing code presumes) that they are defined for
> position-independent code, as distinguished from code for shared
> libraries?  Could you move the definition of these macros out of specs and
> into a single place in the compiler, depending on flag_pic etc.?

There are way more difference between -fno-pic and -fpic than between
-fpic and -fpie and I haven't ever seen code which would use __pic__
or __PIC__ to determine if a locally defined non-static variable
can be accessed through @GOTOFF or whether some function can be inlined at
-O3. __PIC__/__pic__ is used for things like saving/restoring pic register
around inline asm etc., things which apply the same way to -fpic and -fpie.
Most of the spec files which do {fpic: -> {fpic|fpie: are for ASM_SPEC
and similar which are target dependent.
__PIC__ and __pic__ definitions are also target dependent, so IMHO it cannot
be done globally but has to be kept in target headers.
The __PIC__/__pic__ definitions should be done in TARGET_OS_CPP_BUILTINS
and similar macros, like it is done for most GCC targets these days
(for them I did not have to do these changes, they already do
things like:
        if (flag_pic)                           \
          {                                     \
            builtin_define ("__PIC__");         \
            builtin_define ("__pic__");         \
          }                                     \
and flag_pic is 1/2 if flag_pie is 1/2). But rewriting all the CPP_SPECs
etc. to *CPP_BUILTINS macros would require testing on all those arches,
so I'd prefer if that conversion was done by the port maintainers instead.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]