This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]