public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: john.carter@tait.co.nz
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Fedora Core 3 - Ecos synth crashes.
Date: Wed, 04 May 2005 22:45:00 -0000	[thread overview]
Message-ID: <20050504224457.AF28365C064@smtp.ecoscentric.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0505041151550.10409@parore.tait.co.nz> (message from John Carter on Thu, 05 May 2005 10:08:18 +1200 (NZST))

>>>>> "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

  reply	other threads:[~2005-05-04 22:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04 22:08 John Carter
2005-05-04 22:45 ` Bart Veer [this message]
2005-05-04 23:56   ` John Carter
2005-05-05 16:57     ` Bart Veer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050504224457.AF28365C064@smtp.ecoscentric.com \
    --to=bartv@ecoscentric.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=john.carter@tait.co.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).