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: [testsuite] PATCH: Add check_effective_target_pie

"H.J. Lu" <> writes:

> On Wed, Feb 11, 2015 at 7:19 AM, Rainer Orth
> <> wrote:
>> "H.J. Lu" <> writes:
>>> On Wed, Feb 11, 2015 at 6:10 AM, Rainer Orth
>>> <> wrote:
>>>> "H.J. Lu" <> writes:
>>>>>> The new proc is bogus, unfortunately: there's already an existing
>>>>>> check_effective_target_pie that checks if a target can support PIE.  The
>>>>>> new one just overrides the previous one.  On targets supporting PIE
>>>>>> (like Darwin), but not defaulting to it, the PIE tests suddenly turn out
>>>>>> You should rename the new one to
>>>>>> e.g. check_effective_target_pie_default, update the single user, and
>>>>>> document it in sourcebuild.texi.
>>>>> I checked in this as an obvious fix.
>>>> I think pie_enabled is not a very descriptive name:
>>>> Index: doc/sourcebuild.texi
>>>> ===================================================================
>>>> --- doc/sourcebuild.texi (revision 220617)
>>>> +++ doc/sourcebuild.texi (working copy)
>>>> @@ -1884,6 +1884,9 @@
>>>>  @item nonpic
>>>>  Target does not generate PIC by default.
>>>> +@item pie_enabled
>>>> +Target generates PIE by default.
>>>> +
>>>>  @item pcc_bitfield_type_matters
>>>>  Target defines @code{PCC_BITFIELD_TYPE_MATTERS}.
>>>> With -fpie, PIE is also enabled, just not the default without any
>>> I was testing
>>> # make RUNTESTFLAGS="--target_board='unix{-m32\ -fpie,-fpie}'
>>> I don't consider PIE is default.  It is just enabled.
>>>> options.  Please either go with the pie_default I sugested or wait for
>>>> others to weigh in before rushing in another `obvious' fix.
>> Then the description (both sourcebuild.texi and target-supports.texi) is
>> confusing.
> That is how other options are described.

You're not getting my point:

* target-supports.exp now has

# Return 1 if the current multilib generates PIE by default.

* sourcebuild.texi states

Target generates PIE by default.

Which one is it?

>> What are you trying to achieve here, actually?  Even on Solaris 11/x86
>> (which doesn't support PIE), -fpie lets the
>> check_effective_target_pie_enabled (or whatever it's called) proc pass.
>> Shouldn't it also check if the target can support PIE at all?
> Assembly outputs may be different, depending on if PIE is
> enabled nor not. When we scan assembly outputs for test
> results, we have different expected results when PIE is enabled.
> That is how pie_enabled is used so far.

But why would you need a new effective-target keyword for that?  Simply
test the existing { target pie }, add -fpie and scan the assembler
output.  Why would you need pie_enabled or whatever at all?  Again: what
are you trying to achieve that cannot be done with the current keyword?

Right now, in, you're only testing the PIE case
when PIE has been enabled by some means external to testsuite.  The test
always comes out UNSUPPORTED if not, so it isn't even exercised in a
regular bootstrap (except on Darwin which defaults to PIE, I believe).


Rainer Orth, Center for Biotechnology, Bielefeld University

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