This is the mail archive of the
mailing list for the eCos project.
Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Alex Schuilenburg <alex at schuilenburg dot org>
- Cc: Ilija Kocho <ilijak at siva dot com dot mk>, Alex Schuilenburg <alexs at ecoscentric dot com>, eCos developers <ecos-devel at ecos dot sourceware dot org>
- Date: Sun, 4 Mar 2012 20:49:25 +0300 (FET)
- Subject: Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
- Authentication-results: mr.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 10.14.133.198 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org
- References: <4F106345.email@example.com> <4F11574D.firstname.lastname@example.org> <4F11AC54.email@example.com> <4F1CB41C.firstname.lastname@example.org> <4F1DA9A0.email@example.com> <4F1FF5AD.firstname.lastname@example.org> <4F39887A.email@example.com> <4F50F700.firstname.lastname@example.org> <4F521D6A.email@example.com> <4F52B2C8.firstname.lastname@example.org>
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
I just wonder, is there
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
set cyg_test_is_simulator=0 <-- New GDB will stop here
for i in $(find install/tests -type f)
arm-eabi-nm $i | grep cyg_test_is_simulator
shows that only a very few eCos tests are compiled with GCC 4.6 have
cyg_test_is_simulator variable in .data.
% arm-eabi-nm install/tests/hal/common/current/tests/basic | grep simulator
(gdb) set cyg_test_is_simulator=0 <- ?! (no error)
PASS:<HAL_xSBIT_INDEX() basic functions>
PASS:<hal_setjmp()/hal_longjmp() basic functions>
EXIT:<HAL basic functions test>
(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
Well, it is just a guess, no more that. For default template only these tests
have simulator flag:
And my gdbinit had no
By this reason it was possible for me to run long GDB batch jobs on my target
> Managing Director/CEO eCosCentric Limited
> www.ecoscentric.com Reg in England and Wales, Reg No 4422071