From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18766 invoked by alias); 4 Mar 2012 23:47:48 -0000 Received: (qmail 18680 invoked by uid 22791); 4 Mar 2012 23:47:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 04 Mar 2012 23:47:32 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 47B802F78005; Sun, 4 Mar 2012 23:47:31 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeMhlCQpkYND; Sun, 4 Mar 2012 23:47:29 +0000 (GMT) Received: from [192.168.4.131] (aapie.schuilenburg.org [82.153.175.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Alexander Schuilenburg", Issuer "StartCom Class 2 Primary Intermediate Client CA" (verified OK)) (Authenticated sender: alexs@ecoscentric.com) by mail.ecoscentric.com (Postfix) with ESMTP id 3CE9C2F78001; Sun, 4 Mar 2012 23:47:29 +0000 (GMT) Message-ID: <4F53FF0D.80107@ecoscentric.com> Date: Sun, 04 Mar 2012 23:47: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: John Dallaway CC: Ilija Kocho , eCos developers Subject: Re: eCos GNU tools 4.6.2-20120125 ready for testing 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> <4F53C46B.4090502@dallaway.org.uk> In-Reply-To: <4F53C46B.4090502@dallaway.org.uk> 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/msg00007.txt.bz2 On 04/03/2012 19:37, John Dallaway wrote: > Hi Alex > > 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). > An incompatibility between eCos RAM startup application code and the > eCosPro build of RedBoot for this platform seems more likely. Could be. I was basing my hypothesis off the fact that the LPC2468-32 was run in the farm as part of the eCos 3.0 public release and the RedBoot on that board is dated April 2008 so at some point I assumed anoncvs eCos ran successfully. >> 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. > That is useful info, thank you. Could you provide examples of the > infinite backtrace please? We need to understand which of the backtrace > backstops is missing or ineffective. kexcept1 and except1 backtrace fail in every perm with 7.3 gdb. 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. [...] > FYI, I have just built ROM RedBoot and the tm_basic kernel test for > STM3210E-EVAL from latest CVS sources using the new arm-eabi test > release toolchain (4.6.2-20120125). I can confirm that there is no issue > with running this (RAM startup) test via this RedBoot image and hitting > breakpoints at cyg_test_init() and cyg_test_exit(). There are many > people using this board within the eCos community and I believe that > eCos/RedBoot support for STM3210E-EVAL is solid. It should be - we contributed it ;-) This is useful info at least and does point to an incompatibility issue between the eCos and eCosPro RedBoot. I will put the RedBoot built from anoncvs onto both boards and restart... > > However, this success was achieved using arm-eabi-gdb 6.8.50.20080706. > There does appear to be an issue with the length of the 'g' packet when > using the new arm-eabi-gdb 7.3.1: > >> (gdb) tar rem /dev/ttyS0 >> Remote debugging using /dev/ttyS0 >> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021 >> (gdb) Ooops. I had forgotten to reload our test client to use the newer gdb when I reported the first couple of tests had passed. We also see the same failure. -- Alex