This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Release 2.22: Next week ... (m68hc11 testsuite)
On Dec 20, 2011, at 2:51 PM, James Murray wrote:
> Previously I wrote:
>> However, I'm stuck on the S-records test, it reports:
>>
>> m9s12x-elf-gcc -B/usr/src/jsm/build/binout-9s12x/ld/tmpdir/gas/
>> -I/usr/src/jsm/binutils-cvs/binutils-20111216/ld/testsuite/ld-srec -g
>> -O2 -fomit-frame-pointer
>>
> -c /usr/src/jsm/binutils-cvs/binutils-20111216/ld/testsuite/ld-srec/sr2.c >=
> -o tmpdir/sr2.o
>> Executing on host: sh -c {m9s12x-elf-gcc
>> -B/usr/src/jsm/build/binout-9s12x/ld/tmpdir/gas/
>> -I/usr/src/jsm/binutils-cvs/binutils-20111216/ld/testsuite/ld-srec -g
>> -O2 -fomit-frame-pointer
>>
> -c /usr/src/jsm/binutils-cvs/binutils-20111216/ld/testsuite/ld-srec/sr2.c >=
> -o tmpdir/sr2.o 2>&1} /dev/null ld.tmp (timeout = 300)
>> spawn [open ...]
>> /usr/src/jsm/build/binout-9s12x/ld/ld-new -o tmpdir/sr1
>> --traditional-format -G 0 --defsym __stack_chk_fail=3D3D0 --defsym
>> _start=0xc000 tmpdir/sr1.o tmpdir/sr2.o
>> Executing on host: sh -c {/usr/src/jsm/build/binout-9s12x/ld/ld-new
>> -o tmpdir/sr1 --traditional-format -G 0 --defsym __stack_chk_fail=0
>> --defsym _start=0xc000 tmpdir/sr1.o tmpdir/sr2.o 2>&1} /dev/null
> ld.tmp
>> (timeout = 300)
>> spawn [open ...]
>> /usr/src/jsm/build/binout-9s12x/ld/ld-new -o tmpdir/sr2.sr
>> --traditional-format -G 0 --defsym __stack_chk_fail=0 --defsym
>> _start=0xc000 --oformat srec tmpdir/sr1.o tmpdir/sr2.o
>> Executing on host: sh -c {/usr/src/jsm/build/binout-9s12x/ld/ld-new
> -o
>> tmpdir/sr2.sr --traditional-format -G 0 --defsym __stack_chk_fail=0
>> --defsym _start=0xc000 --oformat srec tmpdir/sr1.o tmpdir/sr2.o
>> 2>&1} /dev/null ld.tmp (timeout = 300)
>> spawn [open ...]
>> /usr/src/jsm/build/binout-9s12x/ld/ld-new: can not size stub section:
>> Invalid operation
>> /usr/src/jsm/build/binout-9s12x/ld/ld-new: can not size stub section:
>> Invalid operation
>> FAIL: S-records
>
> The error is being generated here in ld/emultempl/m68hc1xelf.em
> --------------------------
> static void
> m68hc11_elf_${EMULATION_NAME}_before_allocation (void)
> {
> lang_memory_region_type* region;
> int ret;
>
> gld${EMULATION_NAME}_before_allocation ();
>
> /* If generating a relocatable output file, then we don't
> have to generate the trampolines. */
> if (link_info.relocatable)
> return;
>
> ret = elf32_m68hc11_setup_section_lists (link_info.output_bfd,
> &link_info);
> if (ret != 0 && no_trampoline == 0)
> {
> if (ret < 0)
> {
> einfo ("%X%P: can not size stub section: %E\n");
> return;
> }
> --------------------------
> ret has the value -1
>
> Any ideas on whether this is a real problem or if the test is never
> going to work on m68hc11
> It looks as though this might have never worked?
AFAIK, generating directly srec from the elf linker is broken on many targets. I would consider them as XFAIL.
Tristan.