This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH][ARM]Use different startfile and endfile for elf target when generating shared object.


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


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