Bug #640
closed
gcc crash when building lttng-tools on ARM with -fPIE
Added by Yannick Brosseau about 11 years ago.
Updated over 9 years ago.
Description
Tried on lttng-tools 2.3 with gcc 4.8.1:
CC="-O2 -g -Wall -fPIE" ./configure --disable-lttng-ust
Output:
CC consumer.o
consumer.c: In function ‘consumer_snapshot_channel’:
consumer.c:1302:1: internal compiler error: in gen_movsi, at config/arm/arm.md:5539
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
It's a gcc bug probably, but I leave it here to make sure lttng users are aware of it.
Also reproduced with gcc (GCC) 4.7.2
the "-fPIC" option seems to be more commonly used that "-fPIE". Can you reproduce this issue with "-fPIC" ?
I find it weird that you pass PIE as compiler option for the entire lttng-tools project, since this will also apply to objects built for shared objects. If I understand the gcc(1) man page correctly, PIC seems to work both for executable and shared objects, but PIE seems to be only for executables.
Thoughts ?
Thanks,
Mathieu
Its the standard flags for Fedora for building packages. PIE implies I think, but PIE is necessary as part of the "hardening" process
Hi,
I ran into the same issue with -fPIC (which is indeed my default configuration).
Notice how I'm cross-compiling.
../../../arm-linux-gnueabi-libtool --tag=CC --mode=compile arm-linux-gnueabi-gcc -DHAVE_CONFIG_H -I../../.. -I../../.. -I../../../src -I../../../include -include config.h -I../../../include -I../../../src -I/opt/eldk/armv5te/sysroots/armv5te-linux-gnueabi/usr/include -Wall -O2 -pipe -g -feliminate-unused-debug-types -g -fno-strict-aliasing -MT kernel-consumer.lo -MD -MP -MF .deps/kernel-consumer.Tpo -c -o kernel-consumer.lo kernel-consumer.c
arm-linux-gnueabi-libtool: compile: arm-linux-gnueabi-gcc -DHAVE_CONFIG_H -I../../.. -I../../.. -I../../../src -I../../../include -include config.h -I../../../include -I../../../src -I/opt/eldk/armv5te/sysroots/armv5te-linux-gnueabi/usr/include -Wall -O2 -pipe -g -feliminate-unused-debug-types -g -fno-strict-aliasing -MT kernel-consumer.lo -MD -MP -MF .deps/kernel-consumer.Tpo -c kernel-consumer.c -fPIC -DPIC -o .libs/kernel-consumer.o
kernel-consumer.c: In function 'lttng_kconsumer_snapshot_channel':
kernel-consumer.c:322:1: warning: label 'end' defined but not used [-Wunused-label]
kernel-consumer.c:320:1: warning: label 'end_unlock' defined but not used [-Wunused-label]
kernel-consumer.c:314:1: warning: label 'error_put_subbuf' defined but not used [-Wunused-label]
kernel-consumer.c:121:33: warning: unused variable 'channel' [-Wunused-variable]
kernel-consumer.c:120:30: warning: unused variable 'produced_pos' [-Wunused-variable]
kernel-consumer.c:120:16: warning: unused variable 'consumed_pos' [-Wunused-variable]
kernel-consumer.c:315:26: warning: 'stream' is used uninitialized in this function [-Wuninitialized]
kernel-consumer.c: In function 'lttng_kconsumer_snapshot_metadata':
kernel-consumer.c:419:1: internal compiler error: in gen_movsi, at config/arm/arm.md:5452
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (GCC) 4.7.2
Did anyone ever come up with a workaround for this?
AFAICT, Removing -fPIC (that is, issuing --without-pic to ./configure) "fixes" the issue.
A similar issue (due to a ARM specific gcc bug) has been experienced when compiling lttng-tools in O2. Try compiling in O1 instead.
Yes, using -O1 (CFLAGS=-O1 ./configure) solves my problem. Thank you!
For some reason (or maybe I was simply wrong to begin with), using -O1 leads to:
health_state: TLS reference in ../../../src/common/.libs/libconsumer.a(consumer.o) mismatches non-TLS reference in ../../../src/common/.libs/libconsumer.a(consumer-timer.o)
../../../src/common/.libs/libconsumer.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
Looks like I have to use -O0 instead.
- Status changed from New to Feedback
According to the gcc bug tracker entry posted above, the fix is now available in gcc 4.8.3+. Can you confirm that this issue has been fixed?
- Status changed from Feedback to Resolved
Also available in: Atom
PDF