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