From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7079 invoked by alias); 14 Oct 2003 15:09:45 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 7070 invoked from network); 14 Oct 2003 15:09:43 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sources.redhat.com with SMTP; 14 Oct 2003 15:09:43 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1A9Qnw-0006Fa-00; Tue, 14 Oct 2003 17:09:44 +0200 Date: Tue, 14 Oct 2003 15:09:00 -0000 To: James Yates Cc: ecos-discuss@sources.redhat.com Message-ID: <20031014150944.GA24007@lunn.ch> Mail-Followup-To: James Yates , ecos-discuss@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Andrew Lunn Subject: Re: [ECOS] Problems with test X-SW-Source: 2003-10/txt/msg00222.txt.bz2 On Tue, Oct 14, 2003 at 03:31:40PM +0100, James Yates wrote: > Oops my apologies. Yes the version of gcc I am using was one that I > downloaded with the latest version of eCos using the > ecos-install.tcl script. > After much playing around with configurations I have discovered that > if I build with -O2 specified as a Build Flag, i get a segmentation > fault when building mqueue1 test. If I specifiy -O1 or no > optimization this problem goes away. So for the moment I have > optimization at level 1. Its probably a good idea to report a bug. For one of the files that causes a crash, do the compile again, but add -save-temps. You will then get some extra files generated. Goto http://bugs.ecos.sourceware.org/query.cgi and create a new bug report and attach the temp files. > This has enabled to build most tests, although some of the > clock tests in Libc time have failed due to cache problems. I have > no cache defined since the SH2 I am using has no on-chip cache, this > has caused me problems in various areas of the tree. I have had to > resort to defining the various cache related functions to asm("nop") > in my variant src to save having to make changes throughout the > entire source. Is this a valid thing to do? I've not looked at the SH2 code before today..... It looks like a better solution would be to add a new CYGARC_SH_MOD_CAC. You can then make the HAL macros empty statements and set the HAL_?CACHE_SIZE to 0. This will tell eCos you don't have a cache. We can then add this to anoncvs. Andrew -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss