This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Fedora Core 3 - Ecos synth crashes.
- From: Bart Veer <bartv at ecoscentric dot com>
- To: john dot carter at tait dot co dot nz
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 4 May 2005 23:44:57 +0100 (BST)
- Subject: Re: [ECOS] Fedora Core 3 - Ecos synth crashes.
- References: <Pine.LNX.4.61.0505041151550.10409@parore.tait.co.nz>
>>>>> "John" == John Carter <john.carter@tait.co.nz> 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
<snip>
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
<snip>
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