Re: [ECOS] Fedora Core 3 - Ecos synth crashes.

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "John" == John Carter <john.carter@tait.co.nz> 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 <john.carter@tait.co.nz> 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