Re: [PATCH][ARM]Use different startfile and endfile for elf target when generating shared object.

[Renlin Li <renlin.li@foss.arm.com>]

Hi Christophe,

On 13/01/17 11:14, Christophe Lyon wrote:
> On 13 January 2017 at 11:22, Renlin Li <renlin.li@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.

Regards,
Renlin