Re: Release 2.22: Next week ... (m68hc11 testsuite)

[Tristan Gingold <gingold at adacore dot com>]

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.