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

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

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
> 
> 
>