This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Release 2.22: Next week ...
On Mon, 2011-12-19 at 10:35 +0100, Tristan Gingold wrote:
> On Dec 18, 2011, at 6:45 PM, James Murray wrote:
>
> > On 17/11/11 14:50, Tristan Gingold wrote:
> >
> > References: <ADFB3A72-FDFA-4402-A6D5-CADEA94D0ED2@adacore.com>
> > <1747C46F-9EE9-4FE6-B84C-09DC53F21DE0@adacore.com>
> > <2E7397C5-D6E3-4DEC-812E-156DEBA441A8@adacore.com>
> >
> >> I have run the testsuite for most of the targets.
> >> m68hc11-elf: OK
> >
> > Seems ok, but what about the sub-targets? They fail the test-suite.
> > m68hc11-elf PASS
> > m68hc12-elf - 10 gas failures
> > m6811-elf - 5 gas failures
> > m6812-elf - 15 gas failures
>
> Clearly there are targets and sub targets that I don't test.
>
> > Does this matter? Should the tests only be run with the 'main' target?
>
> It is of course better to test as many targets as you can when submitting patches.
>
OK, what I've learned is that the tests fail if gcc is available for
that sub-target, otherwise the failing ld tests are skipped and the
target passes. (Hence for me m68hc11 passed and m9s12x failed.)
The ten FAILS are:
FAIL: Check --gc-section
FAIL: Check --gc-section/-q
FAIL: plugin claimfile lost symbol
FAIL: plugin claimfile replace symbol
FAIL: plugin claimfile resolve symbol
FAIL: plugin claimfile replace file
FAIL: plugin ignore lib
FAIL: plugin claimfile replace lib
FAIL: NOCROSSREFS 3
FAIL: S-records
Nine of them are fixed by target conditionally adding
-fomit_frame_pointer to the cflags/CFLAGS
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=0 --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
(I've cleaned up a warning about _start not being defined for that
target.)
>
> The maintainer will take the decision.
>
Unfortunately, it seems that I'm currently the closest thing to a
maintainer of the m68hc11 target. If anyone else is out there I'd be
keen to work with them.
regards
James Murray