From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29106 invoked by alias); 4 May 2005 22:08:44 -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 28545 invoked from network); 4 May 2005 22:08:22 -0000 Received: from unknown (HELO gatekeeper.tait.co.nz) (202.37.96.21) by sourceware.org with SMTP; 4 May 2005 22:08:22 -0000 Received: from gatekeeper.tait.co.nz (merlin.tait.co.nz [127.0.0.1]) by localhost.tait.co.nz (Postfix) with ESMTP id 78D0615B6A9 for ; Thu, 5 May 2005 10:08:20 +1200 (NZST) Received: from sunstrike.tait.co.nz (unknown [172.25.40.92]) by gatekeeper.tait.co.nz (Postfix) with ESMTP id CDF5115B69D for ; Thu, 5 May 2005 10:08:19 +1200 (NZST) Received: from conversion-daemon.sunstrike.tait.co.nz by sunstrike.tait.co.nz (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) id <0IFZ00201HNO6L00@sunstrike.tait.co.nz> (original mail from john.carter@tait.co.nz) for ecos-discuss@ecos.sourceware.org; Thu, 05 May 2005 10:08:19 +1200 (NZST) Received: from parore.tait.co.nz ([172.25.140.12]) by sunstrike.tait.co.nz (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTP id <0IFZ00H6RK5VH090@sunstrike.tait.co.nz> for ecos-discuss@ecos.sourceware.org; Thu, 05 May 2005 10:08:19 +1200 (NZST) Received: from localhost ([127.0.0.1] ident=johnc) by parore.tait.co.nz with esmtp (Exim 4.34) id 1DTS2V-0005Kw-0Y for ecos-discuss@ecos.sourceware.org; Thu, 05 May 2005 10:08:19 +1200 Date: Wed, 04 May 2005 22:08:00 -0000 From: John Carter X-X-Sender: johnc@parore.tait.co.nz To: ecos-discuss@ecos.sourceware.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Apparently-From: mars X-Contents: May contain traces of nuts. Subject: [ECOS] Fedora Core 3 - Ecos synth crashes. X-SW-Source: 2005-05/txt/msg00041.txt.bz2 I'm seeing a case on fedora core 3 where... * exactly the same executable whether built under fedora or built under debian (both built using the ecosV2.0 gnutools i386-elf-gcc) * seg faults under Fedora (on two different machines) (linux-2.6.9) * Works under debian unstable / Mandrake 9.1 / Mandrake 10 linux-2.4, 2.6.10&12 My current guess, following things around in the debugger is it is during running the __CTOR__ list, in particular setting up the sigactions. Initially I thought it is due to a mismatch between the current linux sigaction struct and the cyg_hal_sys_action struct. (Valgrind certinaly suggested that this may be the case.) I tried fixing that but it didn't resolve the problem. My current best guess is things turn to custard when the SIGALRM's start firing. Looking ecos CVS I note 7 weeks ago Bart Veer was doing something in relation with sigreturn so I wonder if it is worth back patching that, and if so how much do I need? (Curiosly enough this all works under Linux 2.6.12-rc3, 2.610 but not underfedora 2.6.9) ---------------------------------------------------------------------- Here is a description of the difference between the linux and the cyg_hal_sys_sigaction structs.... http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/synth/arch/current/include/hal_io.h?rev=1.13&content-type=text/x-cvsweb-markup&cvsroot=ecos // The kernel sigaction structure has changed, to allow for >32 // signals. This is the old version, i.e. a struct old_sigaction, for // use with the sigaction() system call rather than rt_sigaction(). It // is preferred to the more modern version because gdb knows about // rt_sigaction() and will start intercepting signals, but it seems to // ignore sigaction(). struct cyg_hal_sys_sigaction { void (*hal_handler)(int); long hal_mask; int hal_flags; void (*hal_restorer)(void); }; However, looking in /usr/include/bits/sigaction.h struct sigaction { /* Signal handler. */ #ifdef __USE_POSIX199309 union { /* Used if SA_SIGINFO is not set. */ __sighandler_t sa_handler; /* Used if SA_SIGINFO is set. */ void (*sa_sigaction) (int, siginfo_t *, void *); } __sigaction_handler; # define sa_handler __sigaction_handler.sa_handler # define sa_sigaction __sigaction_handler.sa_sigaction #else __sighandler_t sa_handler; #endif /* Additional set of signals to be blocked. */ __sigset_t sa_mask; /* Special flags. */ int sa_flags; /* Restore handler. */ void (*sa_restorer) (void); }; Where, and this is the interesting bit... /usr/include/bits/sigset.h says # define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int))) typedef struct { unsigned long int __val[_SIGSET_NWORDS]; } __sigset_t; ie. Ecos thinks sa_mask is one int, linux thinks it's 32 int's in a row. If a sigaction is near the edge of available VM a call to sigaction crashes, otherwise it magically (sort of) works. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand Somewhere on the edge of a Galaxy, one of literally billions of such galaxies, is a sun, one of literally billions of suns in that galaxy. Orbiting that sun is a small rock 330000 times smaller than that sun. This rock is covered by a very very thin scum of life. (Think 6000km of rock followed by a meter or so of biomass.) Amongst the millions of species in that scum are many hundreds of thousands of types beetle and a mere handful of primates. Surprisingly enough, this email does not originate from a beetle. It originates from just one of the 6 billion vastly outnumbered humans. I trust you will keep this perspective and context in mind when reacting to this email. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss