Hi,
I'm one of the contributors working to bring Fedora 15 and onwards to
the ARM platform. (yes, F15 is painfully old, but its the first step
in us "catching up")
We have found a ld segfault that occurs early in the gcc compile
process - the first time it tries to link cc1. This is testing on
armv5tel.
/usr/bin/ld --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu
-export-dynamic -dynamic-linker /lib/ld-linux.so.3 -X -m
armelf_linux_eabi -o cc1
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/../../../crt1.o
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/../../../crti.o
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/crtbegin.o
-L/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1
-L/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/../../.. c-lang.o
c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o arm-c.o cc1-checksum.o
main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
../libcpp/libcpp.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -ldl -lz -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/crtend.o
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/../../../crtn.o
Program received signal SIGSEGV, Segmentation fault.
sha1_process_block (buffer=<value optimized out>, len=<value optimized out>,
ctx=0x6a578500) at ./sha1.c:319
319 while (words < endp)
Missing separate debuginfos, use: debuginfo-install
glibc-2.13-2.1.armv5tel libgcc-4.5.1-5.fc14.1.armv5tel
zlib-1.2.5-2.fc14.armv5tel
(gdb)
(gdb) bt
#0 sha1_process_block (buffer=<value optimized out>,
len=<value optimized out>, ctx=0x6a578500) at ./sha1.c:319
#1 0x000348c8 in sha1_process_bytes (buffer=0x43ef2068, len=42803016,
ctx=0xbefff430) at ./sha1.c:245
#2 0x4006fc44 in bfd_elf32_checksum_contents (abfd=0x92530,
process=0x34808 <sha1_process_bytes>, arg=0xbefff430) at elfcode.h:1182
#3 0x0002d090 in gldarmelf_linux_eabi_write_build_id_section (abfd=0x90558)
at earmelf_linux_eabi.c:1394
#4 0x400790d8 in _bfd_elf_write_object_contents (abfd=0x90558) at elf.c:5321
#5 0x4004301c in bfd_close (abfd=0x90558) at opncls.c:699
#6 0x000229fc in main (argc=10000, argv=0x43) at ./ldmain.c:497
Here is another report of the same thing:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/759507
This is 100% reproducible, but does not occur in the latest binutils.
If possible, we'd like to backport the fix rather than introduce a
major binutils upgrade in an old and stable distro branch.
I have identified that binutils-2.21.51.0.9 is the last binutils
version that reproduces the problem, binutils-2.21.52.0.1 is fine.
If someone recognises this issue or wouldn't mind taking a quick look
at the differences between these 2 versions to help us cherry-pick the
exact fix, it would be much appreciated.
Here is the diff between the two versions:
http://dev.laptop.org/~dsd/20110924/binutils-2.21.51.0.8-to-binutils-2.21.51.0.9.diff
Thanks,
Daniel
