This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fedora Core 3 - Ecos synth crashes.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]