gcc corrections for better pie support

[Peter S. Mazinger]

On Tue, 9 Nov 2004, Thiemo Seufer wrote:

> Peter S. Mazinger wrote:
> > On Tue, 9 Nov 2004, Daniel Jacobowitz wrote:
> > 
> > > On Tue, Nov 09, 2004 at 10:32:49AM -0800, Zack Weinberg wrote:
> > > > >> > +%{fno-PIC|fno-pic:-U__PIC__ -U__pic__} %{pthread:-D_REENTRANT}"
> > > > >> 
> > > > >> This should not be necessary; giving -fno-PIC/-fno-pic should cause
> > > > >> flag_pic to be off, and thus the symbols will never get defined in the
> > > > >> first place.  If this is not so, then that is itself a bug that needs
> > > > >> fixing.
> > > > >
> > > > > on mips builtin_define __PIC__ and __pic__ are not ifdef'd by flag_pic 
> > > > > (probably because it's a PIC arch) so I think the disable logic won't work
> > > > > see gcc/config/mips/linux.h line 59/60.
> > > > 
> > > > Well, like I said, that is itself a bug, and you need to address the
> > > > problem there - best is to leave MIPS alone for now and consult with
> > > > the MIPS maintainers (see the MAINTAINERS file at top level of the
> > > > source tree for their names) how to straighten it all out.
> > > 
> > > It isn't a bug.  MIPS Linux code is always PIC.
> > is than the above line beginning w/%{fno-PIC... necessary?
> 
> MIPS Linux Userland code is always PIC, while the Kernel is always non-PIC.

the kernel can be built on all archs w/ __PIC__ / __pic__ , so that is not 
relevant (and I haven't seen using fno-PIC in kernel-sources.)

> So defining __PIC__ / __pic__ unconditionally seems to be a (until now
> harmless) bug.

is there a known case where
-U__PIC__ / -U__pic__ is needed?

or

Is it possible/allowed to build a non-PIC exec on MIPS?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2