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