gcc corrections for better pie support

Richard Sandiford rsandifo@redhat.com
Tue Nov 9 21:19:00 GMT 2004


"Peter S. Mazinger" <ps.m@gmx.net> writes:
>> "Peter S. Mazinger" <ps.m@gmx.net> writes:
>> > diff -urN gcc.old/gcc/config/mips/linux.h gcc/gcc/config/mips/linux.h
>> > --- gcc.old/gcc/config/mips/linux.h	Wed Sep  8 02:17:15 2004
>> > +++ gcc/gcc/config/mips/linux.h	Mon Nov  8 11:04:47 2004
>> > @@ -97,9 +97,7 @@
>> >  
>> >  #undef  SUBTARGET_CPP_SPEC
>> >  #define SUBTARGET_CPP_SPEC "\
>> > -%{fno-PIC:-U__PIC__ -U__pic__} %{fno-pic:-U__PIC__ -U__pic__} \
>> > -%{fPIC|fPIE|fpic|fpie:-D__PIC__ -D__pic__} \
>> > -%{pthread:-D_REENTRANT}"
>> > +%{fno-PIC|fno-pic:-U__PIC__ -U__pic__} %{pthread:-D_REENTRANT}"
>> >  
>> >  /* From iris5.h */
>> >  /* -G is incompatible with -KPIC which is the default, so only allow objects
>> 
>> I think you should just remove all the PIC stuff from SUBTARGET_CPP_SPEC
>> and guard the builtin_defines in linux.h with flag_shlib instead.
>
> what about guarding the builtin_defines w/ flag_pic as the archs do, but 
> set flag_pic to retain the current behaviour. if later on there will be 
> cases where the builtin_defines shouldn't be used, it can be done by 
> adapting only flag_pic.

The problem is that flag_pic is always set for -mabicalls: see
mips.c:override_options.  So flag_pic ends up being set for -fno-pic.
(Yes, this whole area of the port is mess...)

flag_shlib || flag_pie should make sure that the macros are only
defined if -fpic/-fPIC/-fpie/-fPIE are passed.

>> > @@ -123,7 +121,7 @@
>> >  #define SUBTARGET_ASM_SPEC "\
>> >  %{mabi=64: -64} \
>> >  %{!fno-PIC:%{!fno-pic:-KPIC}} \
>> > -%{fno-PIC:-non_shared} %{fno-pic:-non_shared}"
>> > +%{fno-PIC|fno-pic:-non_shared}"
>> 
>> If this is causing trouble, you should be able to get rid of all the
>> PIC stuff here too.  GAS assumes -non_shared by default and GCC uses
>> .abicalls if it wants -KPIC.

Sorry, just ignore this comment.  I was thinking only about gcc's use
of the assembler.

We need to pass -KPIC by default when using the gcc driver to assemble
user .S and .s files, so we do need to keep the existing options.

Richard



More information about the Gcc-patches mailing list