Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

[Alex Schuilenburg <alex@schuilenburg.org>]

On 03/03/2012 13:32, Ilija Kocho wrote:
> On 02.03.2012 17:36, Alex Schuilenburg wrote:
>> [...]
>> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
>> 00:00:00:00 along with the toolchain above and thrown that to our test
>> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
>> appears to be either incompatible with our RedBoot or is broken in
>> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
>> or run without any breakpoints. I suspect this port appears to have
>> suffered bitrot since the V3 as the board appears to have been run in
>> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
>> the board is dated Apr 25 2008  which goes back to V2.
>>
>> I have just switched to using our eCosPro sources and the first couple
>> of tests I checked passed, so at least this confirms this is not any
>> issue with the toolchain. Using the same set of eCosPro sources with our
>> ecospro tools and the anoncvs tools at least will tell us if there is
>> any regression.  Unfortunately though, if there is a regression we will
>> only be able to report the test/s that failed along with the flags and
>> configuration used to build the tests.  Otherwise somebody is going to
>> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board.
> Thank you Alex.
> I think that the first step is to find out whether it is a problem with
> EA LPC2468-32 code or more general. Unfortunately I am not able to test
> with this board as we don't have one

I am pretty certain it is an issue with the EA LPC2468-32 code in
anoncvs as the eCosPro EA LPC2468-32 builds and runs fine, although it
could be a more general issues with the anoncvs code (see below).

There is only one issue uncovered so far, and that is the backtrace of
gdb 7.3 is unreliable.  It occasionally can end up in an infinite loop,
while our own 7.2 gdb for eCosPro works just fine in exactly the same
tests (i.e. built with gcc 4.6.2).  However, I guess users could add a
"set backtracelimit=100" and that should catch this issue.


> .
> I hope that the testing with STM32 may give us some hint.

anoncvs eCos for the stm3210e_eval board behaves unfortunately in
exactly the same manner.  tests do not even reach cyg_test_init.  I just
did the same switch to the eCosPro source base and the tests run so far
all passed.


> I also wander if test with RedBoot from current CVS would help.
I spoke to Nick Garnett who said there is a remote possibility that the
anoncvs sources have become incompatible with the eCosPro RedBoot, and
given that anoncvs tests for both selected targets die in the same
manner, I will rebuild RedBoot and give it a go.  I'll need to fetch the
boards from the testfarm though (our testfarm is off-site, in a shed on
a "farm" :-) to do this, or maybe just try a RAM redboot first.  I'll
let you know how I get on.

Hopefully it is something simple and not that eCos in anoncvs for both
boards has been subject to bitrot.

-- Alex

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071