On 13 January 2017 at 13:26, Renlin Li <renlin...@foss.arm.com> wrote:
> Hi Christophe,
>
>
> On 13/01/17 11:14, Christophe Lyon wrote:
>>
>> On 13 January 2017 at 11:22, Renlin Li <renlin...@foss.arm.com> wrote:
>>>
>>> Hi Christophe,
>>>
>>> Thanks for testing the patch!
>>> I check the test case gcc.dg/lto/pr54709, it seems the test case is not
>>> properly written.
>>>
>>> It add extra ld option -shared without checking the target support for
>>> that.
>>> After the change, this compilation will fail as a regression.
>>> IIUC, '-shared' option is required, it should be gated with corresponding
>>> target selector.
>>>
>>> "g++.dg/ipa/devirt-28a.C" now is skipped because of the target selector
>>> there.
>>> // { dg-do link { target { { gld && fpic } && shared } } }
>>>
>>> perhaps "gcc.dg/lto/pr54709" should do similar things like this:
>>> // { dg-do link { target { shared } } }
>>
>> Quite likely, indeed.
>>
>>>
>>>
>>> As far as I know, with different cpu/arch configurations, different
>>> relocations are generated in the library, some of the relocations are not
>>> allowed to be used in shared
>>> object.
>>>
>>> With -march=armv7-a (and the --with-cpu=cortex-a9 option you mentioned),
>>> the
>>> linking stage of the test will fail because of this error:
>>> "relocation XXX against external symbol `YYY' can not be used when making
>>> a
>>> shared object"
>>> for instance: crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local
>>> symbol` can not be used when making a shared object; recompile with -fPIC
>>>
>>> If you are luck enough, for example with arm7tdmi cpu, no such relocation
>>> is
>>> generated in startup files. The "shared" target support check will pass
>>> for
>>> simple and naive code.
>>> "--with-cpu=cortex-m3" should be this case. But the test cases which
>>> require
>>> shared object support will fail.
>>>
>>>
>>> So this "shared" target checking mechanism is not reliable. The patch is
>>> to
>>> change this.
>>>
>> Shouldn't your patch imply that several tests move from "fail" to
>> "unsupported" on armv7-a ? I'm surprised not to see any difference in the
>> results.
>>
>>>
>
> Oops, I reordered the explanation paragraphs in my last email, making it
> obscure.
>
> The "shared" target check will fail on armv7-a architecture because of the
> reason
> mentioned below. So they are already been ignored. After the change, they
> are still
> marked as "unsupported", but with a different reason. "crtbeginS.o cannot be
> found"
>
> The deja-gnu test framework will compose a small program to test whether the
> toolchain
> supports "shared" option.
>
>>> With -march=armv7-a (and the --with-cpu=cortex-a9 option you mentioned),
>>> the
>>> linking stage of the test will fail because of this error:
>>> "relocation XXX against external symbol `YYY' can not be used when making
>>> a
>>> shared object"
>>> for instance: crtbegin.o: relocation R_ARM_MOVW_ABS_NC against `a local
>>> symbol` can not be used when making a shared object; recompile with -fPIC
>>>
>
> So the check won't pass, and the test case is marked as "unsupported".
>
>>> If you are luck enough, for example with arm7tdmi cpu, no such relocation
>>> is
>>> generated in startup files. The "shared" target support check will pass
>>> for
>>> simple and naive code.
>>> "--with-cpu=cortex-m3" should be this case. But the test cases which
>>> require
>>> shared object support will fail.
>
> So for the same test case,
> With "--with-cpu=cortex-m3",
> The "shared" target support check will pass. It is marked as supported, but
> fail to produce binary.
> with --with-cpu=cortex-a9",
> The "shared" target support check will fail. it is marked as "unsupported"
> and skipped.
>
> After the change, the test case will marked as "unsupported" regardless of
> the
> cpu/arch configuration.
>
OK thanks for the clarification.> Regards, > Renlin
