[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- (In reply to Ramana Radhakrishnan from comment #13) > (In reply to christophe.lyon from comment #12) > > Created attachment 32864 [details] > > ELF binary file #3 > > > > Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb > > Is this still an issue ? As of today, the test passes on trunk, using binutils-2.27. We can probably close this bug, but I've lost track when it was fixed.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #13 from Ramana Radhakrishnan --- (In reply to christophe.lyon from comment #12) > Created attachment 32864 [details] > ELF binary file #3 > > Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb Is this still an issue ?
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #12 from christophe.lyon at st dot com --- Created attachment 32864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32864&action=edit ELF binary file #3 Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #11 from wangzheyu --- Hi, Could you please provide an elf file compiled with arm-none-linux-gnueabi-gcc -Os -g3 -pie -fpie -mthumb -march=armv5t So that we can debug under our hardware and easy to compared with the former one. Thanks a lot. (In reply to christophe.lyon from comment #10) > Created attachment 32863 [details] > ELF binary file #2 > > Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb > -march=armv5t tls-reload-1.c -o tls-reload-1.exe > > Binutils Linaro 2014.03
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #10 from christophe.lyon at st dot com --- Created attachment 32863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32863&action=edit ELF binary file #2 Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb -march=armv5t tls-reload-1.c -o tls-reload-1.exe Binutils Linaro 2014.03
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #9 from wangzheyu --- Hi, would please provide your elf file with the new binutils, so that we can verify that whether it's the same issue as your former elf. If it is, it can be verified as a bug because you're using the latest binutils-linaro. We will investigate this issue further. Thanks a lot. (In reply to christophe.lyon from comment #8) > Using GCC trunk @210861, binutils-linaro-2.24-2014.03, I can see that > tls-reload-1.c all PASS with: > --target arm-none-linux-gnueabi --with-mode=arm --with-cpu=cortex-a9 > --with-fpu=neon and target_board set to -march=armv5t. > > When changing to --with-mode=thumb, I can see 10 failures at execution time, > with "-pie -fpie" and -pie -fPIE" combined with -O1, -O2, -O3 > -fomit-frame-pointer, -O3 -g, and -Os.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #8 from christophe.lyon at st dot com --- Using GCC trunk @210861, binutils-linaro-2.24-2014.03, I can see that tls-reload-1.c all PASS with: --target arm-none-linux-gnueabi --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon and target_board set to -march=armv5t. When changing to --with-mode=thumb, I can see 10 failures at execution time, with "-pie -fpie" and -pie -fPIE" combined with -O1, -O2, -O3 -fomit-frame-pointer, -O3 -g, and -Os.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #7 from wangzheyu --- After a close analysis of your elf, it will fail due to bad code in first call to function checktls23. The corresponding C code is: if (!y || *y++ != &tls23 || *y++ != &tls23_array[3]) return 0; The code to get address of variable tls23 is wrongly fixed up. Here is the assembly code with analysis embedded: checktls23: push{r4, lr} mov r3, r0 sub r2, r0, #0 beq .L136 ldr r2, .L140 << get offset of variable tls23 ldr r1, [r0] bl __aeabi_read_tp @ load_tp_soft << get thread point and save it to r0 add r0, r0, r2 << thread point plus offset equals address of variable tls23 mov r2, #0 cmp r1, r0 bne .L136 ldr r4, .L140+4 bl __aeabi_read_tp @ load_tp_soft ldr r1, [r3, #4] add r0, r0, r4 cmp r1, r0 bne .L136 add r3, r3, #8 mov r2, r3 .L136: mov r0, r2 @ sp needed pop {r4, pc} .L141: .align 2 .L140: .word .LANCHOR2(tpoff)+124 << offset of tls23 is correctly generated. but never get correctly fixed up. .word .LANCHOR3(tpoff)+12 So my advice is to use a newer version of binutils to test it again. (In reply to christophe.lyon from comment #6) > I have re-run the tests with trunk@210140 and older binutils (Sept 2013). > > The test fails at compilation with target arm-none-linux-gnueabi, and > CFLAGS=-Os -pie -fpie or -Os -pie -fPIE in the following configurations: > --with-mode=arm --with-cpu=cortex-a9 > --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-mthumb > --with-mode=thumb --with-cpu=cortex-a9 > --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-marm > > The test compiles OK and fails at execution with > --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t > (this is the ELF file I have attached) > > The compiles and runs OK with > --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #6 from christophe.lyon at st dot com --- I have re-run the tests with trunk@210140 and older binutils (Sept 2013). The test fails at compilation with target arm-none-linux-gnueabi, and CFLAGS=-Os -pie -fpie or -Os -pie -fPIE in the following configurations: --with-mode=arm --with-cpu=cortex-a9 --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-mthumb --with-mode=thumb --with-cpu=cortex-a9 --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-marm The test compiles OK and fails at execution with --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t (this is the ELF file I have attached) The compiles and runs OK with --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #5 from christophe.lyon at st dot com --- Created attachment 32806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32806&action=edit ELF binary file
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #4 from wangzheyu --- Hi christophe, It's ok from my side, the link time is ok. I'm not sure if it's related to your tool chain version, but would you please provide detailed information of your toolchain, the cmd you run for the test case, and where you get this version binutils? (In reply to christophe.lyon from comment #3) > Sorry I no longer have the elf file available. > I've just looked at the current trunk status and I have a failure at link > time for these tests: > ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not > be used when making a shared object; recompile with -fPIC > gcc_tg.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > compiler exited with status 1 > > Not sure if it's a problem with the binutils I use (linaro-2.24-2013.12) or > a known problem with the GCC test?
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #3 from christophe.lyon at st dot com --- Sorry I no longer have the elf file available. I've just looked at the current trunk status and I have a failure at link time for these tests: ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC gcc_tg.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status compiler exited with status 1 Not sure if it's a problem with the binutils I use (linaro-2.24-2013.12) or a known problem with the GCC test?
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 wangzheyu changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #2 from wangzheyu --- Hi, I'm trying to reproduce this bug on the panda board(cortex-a9). With the same configuration, the case does meet some execution failure, but in order to clarify what happened on earth, could you please provide your own elf? (In reply to christophe.lyon from comment #0) > Since commit 206897 (LRA fix PR rtl-optimization/59858) > I have noticed that: > gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fPIE execution test > gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fpie execution test > > the compiler used to ICE, but after the LRA fix the generated code is not > functional. > > I have tested with qemu-arm, target arm-none-linux-gnueabi, > --with-mode=thumb --with-cpu=cortex-a9, using RUNTESTFLAGS=-march=armv5t > > gcc.log contains: > qemu: uncaught target signal 6 (Aborted) - core dumped
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan --- So, this is failing for TLS with Thumb1, PIE and armv5t. Needs further investigation.