From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13412 invoked by alias); 4 Mar 2012 00:10:10 -0000 Received: (qmail 13399 invoked by uid 22791); 4 Mar 2012 00:10:08 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtpout.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.34) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Mar 2012 00:09:51 +0000 Received: from aapie.schuilenburg.org (HELO mail.schuilenburg.org) ([82.153.175.19]) by smtpout.karoo.kcom.com with ESMTP; 04 Mar 2012 00:09:49 +0000 Received: from localhost (aapie.schuilenburg.org [127.0.0.1]) by mail.schuilenburg.org (Postfix) with ESMTP id 7A4908DA22; Sun, 4 Mar 2012 00:08:47 +0000 (GMT) Received: from mail.schuilenburg.org ([127.0.0.1]) by localhost (aapie.schuilenburg.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGdiuidjF+dD; Sun, 4 Mar 2012 00:08:40 +0000 (GMT) Received: from [192.168.4.131] (linksys.schuilenburg.org [192.168.4.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.schuilenburg.org (Postfix) with ESMTP id 752998DA21; Sun, 4 Mar 2012 00:08:40 +0000 (GMT) Message-ID: <4F52B2C8.4010809@schuilenburg.org> Date: Sun, 04 Mar 2012 00:10:00 -0000 From: Alex Schuilenburg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ilija Kocho CC: 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] 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> In-Reply-To: <4F521D6A.4010500@siva.com.mk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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/msg00003.txt.bz2 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