From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14549 invoked by alias); 5 May 2005 16:57:15 -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 14364 invoked from network); 5 May 2005 16:57:04 -0000 Received: from unknown (HELO smtp.ecoscentric.com) (194.153.168.165) by sourceware.org with SMTP; 5 May 2005 16:57:04 -0000 Received: by smtp.ecoscentric.com (Postfix, from userid 99) id A0C7565C06C; Thu, 5 May 2005 17:57:03 +0100 (BST) Received: from delenn.bartv.net (localhost [127.0.0.1]) by smtp.ecoscentric.com (Postfix) with ESMTP id 99F2265C057; Thu, 5 May 2005 17:57:02 +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 11:55:48 +1200 (NZST)) From: Bart Veer References: <20050504224457.AF28365C064@smtp.ecoscentric.com> Message-Id: <20050505165702.99F2265C057@smtp.ecoscentric.com> Date: Thu, 05 May 2005 16:57:00 -0000 Subject: Re: [ECOS] Fedora Core 3 - Ecos synth crashes. X-SW-Source: 2005-05/txt/msg00049.txt.bz2 >>>>> "John" == John Carter writes: John> On Wed, 4 May 2005, Bart Veer wrote: >> What you are looking at there is a struct sigaction, not a struct >> old_sigaction. John> Hmm, I saw that in the code, but I'm not totally convinced. John> As I read it, somewhere down the bottom of everything the John> linux sigaction system call is made and it is expecting the John> new type sigaction. Linux is expecting distributors to John> recompile #including the new headers which would result in John> it all just working. Unfortunately ecos copies and pastes John> the old struct definition hence remains out of step. John> Valgrind seems to second my reading of this in that it John> whinges about uninitialized data being passed to sigaction John> without my mods, and is happy with them. The synthetic target makes the original sigaction call, system call 67, which takes a struct old_sigaction. There is also rt_sigaction, system call 173, which takes the new version of the structure. These days glibc and hence nearly all Linux applications will use the latter. The Linux kernel supports both system calls and is likely to continue to do so for the foreseeable future to preserve binary compatibility. The synthetic target uses the old call in preference because gdb tries to do some clever stuff for the new call which gets in the way of the synthetic target operation. For further confirmation, consider the structure layout: struct cyg_hal_sys_sigaction { void (*hal_handler)(int); long hal_mask; int hal_flags; void (*hal_restorer)(void); }; If the Linux kernel was expecting 32 ints for sa_mask instead of just one then the supplied flags and restorer fields would be interpreted as part of the sa_mask, and random data would be interpreted as the flags and restorer. This is not what happens. The flags and restorer fields are critical to the correct behaviour of the system, and work as intended. >>>>> "John" == John Carter writes: John> On Wed, 4 May 2005, Bart Veer wrote: >> 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> Ok, that worked. Except for one minor glitch in synth.ld John> We are still using the gnutools i386-elf-gcc version 3.2.1 John> that came with ecos V2.0, which doesn't have libgcc_eh.a and John> libsupc++.a The synthetic target is normally built with the native gcc, not with i386-elf-gcc which is primarily a cross-compiler for real x86 embedded targets. Using i386-elf-gcc is necessary only if you are building on a Windows box and then running the application on a Linux box. Not a common scenario. 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