From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29760 invoked by alias); 4 Mar 2012 17:49:48 -0000 Received: (qmail 29750 invoked by uid 22791); 4 Mar 2012 17:49:45 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ee0-f49.google.com (HELO mail-ee0-f49.google.com) (74.125.83.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Mar 2012 17:49:31 +0000 Received: by eekb45 with SMTP id b45so1437314eek.36 for ; Sun, 04 Mar 2012 09:49:30 -0800 (PST) Received-SPF: pass (google.com: domain of sergei.gavrikov@gmail.com designates 10.14.133.198 as permitted sender) client-ip=10.14.133.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sergei.gavrikov@gmail.com designates 10.14.133.198 as permitted sender) smtp.mail=sergei.gavrikov@gmail.com; dkim=pass header.i=sergei.gavrikov@gmail.com Received: from mr.google.com ([10.14.133.198]) by 10.14.133.198 with SMTP id q46mr9684074eei.64.1330883370471 (num_hops = 1); Sun, 04 Mar 2012 09:49:30 -0800 (PST) Received: by 10.14.133.198 with SMTP id q46mr7371826eei.64.1330883370227; Sun, 04 Mar 2012 09:49:30 -0800 (PST) Received: from vostro ([37.45.114.43]) by mx.google.com with ESMTPS id o49sm50883431eeb.7.2012.03.04.09.49.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Mar 2012 09:49:29 -0800 (PST) Date: Sun, 04 Mar 2012 17:49:00 -0000 From: Sergei Gavrikov To: Alex Schuilenburg cc: Ilija Kocho , Alex Schuilenburg , eCos developers Subject: Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] In-Reply-To: <4F52B2C8.4010809@schuilenburg.org> Message-ID: References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> <4F11AC54.7000902@siva.com.mk> <4F1CB41C.90900@jifvik.org> <4F1DA9A0.5070702@siva.com.mk> <4F1FF5AD.4010901@ecoscentric.com> <4F39887A.5050905@siva.com.mk> <4F50F700.5080902@ecoscentric.com> <4F521D6A.4010500@siva.com.mk> <4F52B2C8.4010809@schuilenburg.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-03/txt/msg00004.txt.bz2 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 GDB 6.8 (gdb) set cyg_test_is_simulator=0 <- ?! (no error) (gdb) cont Continuing. PASS: PASS: EXIT: 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 > > >