Hi,

In attempting to bootstrap gcc in Thumb2 state on an Ubuntu distribution using
ld from cvs as of GNU ld (GNU Binutils) 2.19.51.20090630 as well as GNU ld (GNU
Binutils for Ubuntu) 2.19.51.20090622, I see the following segfault while
linking f951. 

The way I've configured gcc for the bootstrap is to do the following 

/home/ramrad01/sources/trunk/configure
--prefix=/home/ramrad01/installs/install-thumb2-scheduling-fix
--with-cpu=cortex-a8 --with-fpu=neon --with-float=softfp --with-mode=thumb
--enable-languages=c,c++,fortran --disable-stage1-checking


The command line while linking f951 is as follows :
 /home/ramrad01/build-thumb2-no-insn-scheduling/./prev-gcc/collect2
--eh-frame-hdr -export-dynamic -dynamic-linker /lib/ld-linux.so.3 -X -m
armelf_linux_eabi -o f951 /usr/lib/crt1.o /usr/lib/crti.o
/home/ramrad01/build-thumb2-no-insn-scheduling/./prev-gcc/crtbegin.o
-L/home/ramrad01/build-thumb2-no-insn-scheduling/./prev-gcc fortran/arith.o
fortran/array.o fortran/bbt.o fortran/check.o fortran/cpp.o fortran/data.o
fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
fortran/symbol.o fortran/target-memory.o fortran/convert.o fortran/dependency.o
fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o
fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o
fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o
fortran/trans-stmt.o fortran/trans-types.o main.o tree-browser.o libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -lmpfr -lgmp
-ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/home/ramrad01/build-thumb2-no-insn-scheduling/./prev-gcc/crtend.o /usr/lib/crtn.o


A gdb back trace is pasted below. 


#0  arm_build_one_stub (gen_entry=0x1068f8, in_arg=0xf2658) at
/home/ramrad01/sources/src/bfd/elf32-arm.c:3438
#1  0x0003901c in bfd_hash_traverse (table=0x101948, func=0x5333c
<arm_build_one_stub>, info=0xf2658) at /home/ramrad01/sources/src/bfd/hash.c:602
#2  0x000470fc in elf32_arm_build_stubs (info=0xf2658) at
/home/ramrad01/sources/src/bfd/elf32-arm.c:4692
#3  0x000258fc in gldarmelf_linux_eabi_finish () at earmelf_linux_eabi.c:476
#4  0x00020a40 in ldemul_finish () at /home/ramrad01/sources/src/ld/ldemul.c:90
#5  0x0001a698 in lang_process () at /home/ramrad01/sources/src/ld/ldlang.c:6320
#6  0x0001db60 in main (argc=0, argv=0x9874) at
/home/ramrad01/sources/src/ld/ldmain.c:453

The segfault appears to occur because 


3438      stub_entry->stub_offset = stub_sec->size;
(gdb) p stub_sec
$5 = (asection *) 0x0


stub_sec is assigned from stub_entry->stub_sec and stub_entry is essentially
(struct elf32_arm_stub_hash_entry *) gen_entry.

gdb)  p (struct elf32_arm_stub_hash_entry *)gen_entry                
$8 = (struct elf32_arm_stub_hash_entry *) 0x1068f8

(gdb)  p *(struct elf32_arm_stub_hash_entry *)gen_entry
$9 = {root = {next = 0x0, string = 0x32cdf90 "e7f:be6", hash = 106622415},
stub_sec = 0x0, stub_offset = 0, target_value = 3046, target_section =
0x1321fa0, target_addend = 4294964666, 
  orig_insn = 4160748253, stub_type = arm_stub_a8_veneer_bl, stub_size = 4,
stub_template = 0xe00fc, stub_template_size = 1, h = 0x0, st_type = 13 '\r',
id_sec = 0x17312f0, output_name = 0x0}


However if one removes --eh-frame-header from the command line the segfault goes
away. I haven't yet been able to construct a smaller testcase where this problem
occurs I'm afraid . 

This might be related to the A8 erratum fix around given that the stub is of
type arm_stub_a8_veneer_bl but I might be wrong.

Can someone take a quick look at this ?

cheers
Ramana