On Sun, 4 Mar 2012, Alex Schuilenburg wrote:
> 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
Hi Alex
I just wonder, is there
set cyg_test_is_simulator=0
line in your gdbinit file?
I mean that default gdbinit template (generated by eCos configtool) is
set height 0
set debug remote 0
set remotebaud %b
target remote %p
load
break cyg_test_exit
rbreak cyg_assert_fail
break cyg_test_init
cont
set cyg_test_is_simulator=0 <-- New GDB will stop here
cont
bt 64
and this
for i in $(find install/tests -type f)
do
echo $i
arm-eabi-nm $i | grep cyg_test_is_simulator
done
shows that only a very few eCos tests are compiled with GCC 4.6 have
cyg_test_is_simulator variable in .data.
For example,
% arm-eabi-nm install/tests/hal/common/current/tests/basic | grep simulator
<no output>
GDB 6.8
(gdb) set cyg_test_is_simulator=0 <- ?! (no error)
(gdb) cont
Continuing.
PASS:<HAL_xSBIT_INDEX() basic functions>
PASS:<hal_setjmp()/hal_longjmp() basic functions>
EXIT:<HAL basic functions test>
GDB 7.3.1
(gdb) set cyg_test_is_simulator=0
No symbol "cyg_test_is_simulator" in current context.
IMHO, this claim is okay, adn GDB 7.3.1 does not process the next lines in
gdbinit.
Well, it is just a guess, no more that. For default template only these tests
have simulator flag:
install/tests/infra/current/tests/cxxsupp
install/tests/infra/current/tests/diag_sprintf1
install/tests/infra/current/tests/diag_sprintf2
install/tests/kernel/current/tests/fptest
install/tests/kernel/current/tests/kill
install/tests/kernel/current/tests/kclock1
install/tests/kernel/current/tests/dhrystone
install/tests/kernel/current/tests/kmutex4
install/tests/kernel/current/tests/mutex3
install/tests/kernel/current/tests/kmutex3
install/tests/kernel/current/tests/stress_threads
install/tests/kernel/current/tests/clock1
install/tests/kernel/current/tests/bin_sem2
install/tests/kernel/current/tests/tm_basic
install/tests/kernel/current/tests/clockcnv
install/tests/io/wallclock/current/tests/wallclock
install/tests/services/memalloc/common/current/tests/malloc4
install/tests/services/memalloc/common/current/tests/heaptest
And my gdbinit had no
set cyg_test_is_simulator=0
By this reason it was possible for me to run long GDB batch jobs on my target
without stops.
Sergei
> Managing Director/CEO eCosCentric Limited
> www.ecoscentric.com Reg in England and Wales, Reg No 4422071
>
>
>
