From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19549 invoked by alias); 4 May 2005 22:45:09 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 19257 invoked from network); 4 May 2005 22:44:59 -0000 Received: from unknown (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org with SMTP; 4 May 2005 22:44:59 -0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id 9A18D65C071; Wed, 4 May 2005 23:44:58 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id AF28365C064; Wed, 4 May 2005 23:44:57 +0100 (BST) To: john.carter@tait.co.nz Cc: ecos-discuss@ecos.sourceware.org In-reply-to: (message from John Carter on Thu, 05 May 2005 10:08:18 +1200 (NZST)) From: Bart Veer References: Message-Id: <20050504224457.AF28365C064@smtp.ecoscentric.com> Date: Wed, 04 May 2005 22:45:00 -0000 Subject: Re: [ECOS] Fedora Core 3 - Ecos synth crashes. X-SW-Source: 2005-05/txt/msg00042.txt.bz2 >>>>> "John" == John Carter writes: John> I'm seeing a case on fedora core 3 where... John> * exactly the same executable whether built under fedora John> or built under debian (both built using the ecosV2.0 John> gnutools i386-elf-gcc) John> * seg faults under Fedora (on two different machines) John> (linux-2.6.9) John> * Works under debian unstable / Mandrake 9.1 / Mandrake 10 John> linux-2.4, 2.6.10&12 John> My current best guess is things turn to custard when the John> SIGALRM's start firing. John> Looking ecos CVS I note 7 weeks ago Bart Veer was doing John> something in relation with sigreturn so I wonder if it is John> worth back patching that, and if so how much do I need? John> (Curiosly enough this all works under Linux 2.6.12-rc3, John> 2.610 but not underfedora 2.6.9) Yes. The Fedora folks appear to have done something strange to the kernel. I did not try to figure out exactly which of their patches causes the problem. Other distributions are not affected. When a signal handler is invoked the Fedora kernel places a bogus return address on the signal handler's stack so when that signal handler returns things blow up. Most applications are not affected because they go via glibc signal handling code, which triggers a slightly different path through the kernel. What my patch does is basically replicate the glibc behaviour and the problems go away. This is not the only synthetic target problem fixed since the v2 release. There have been a couple of compiler-related issues which had to be worked around. I suggest switching to anoncvs, at the very least everything below hal/synth John> ie. Ecos thinks sa_mask is one int, linux thinks it's 32 John> int's in a row. If a sigaction is near the edge of available John> VM a call to sigaction crashes, otherwise it magically (sort John> of) works. What you are looking at there is a struct sigaction, not a struct old_sigaction. Originally Linux only supported up to 32 signals, each requiring one bit in the sa_mask, so in a struct old_sigaction the sa_mask is just one integer. The synthetic target does not need any of the newer real-time signal support. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss