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]

Fedora Core 3 - Ecos synth crashes.


I'm seeing a case on fedora core 3 where...
 * exactly the same executable whether built under fedora or built under debian (both built using the
   ecosV2.0 gnutools i386-elf-gcc)
 * seg faults under Fedora (on two different machines) (linux-2.6.9)
 * Works under debian unstable / Mandrake 9.1 / Mandrake 10 linux-2.4, 2.6.10&12

My current guess, following things around in the debugger is it is during running the __CTOR__ list, in particular setting up the sigactions.

Initially I thought it is due to a mismatch between the current linux
sigaction struct and the cyg_hal_sys_action struct. (Valgrind
certinaly suggested that this may be the case.) I tried fixing that
but it didn't resolve the problem.

My current best guess is things turn to custard when the SIGALRM's
start firing.

Looking ecos CVS I note 7 weeks ago Bart Veer was doing something in
relation with sigreturn so I wonder if it is worth back patching that,
and if so how much do I need? (Curiosly enough this all works under Linux 2.6.12-rc3, 2.610 but not underfedora 2.6.9)



----------------------------------------------------------------------



Here is a description of the difference between the linux and the cyg_hal_sys_sigaction structs....

http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/synth/arch/current/include/hal_io.h?rev=1.13&content-type=text/x-cvsweb-markup&cvsroot=ecos
// The kernel sigaction structure has changed, to allow for >32
// signals. This is the old version, i.e. a struct old_sigaction, for
// use with the sigaction() system call rather than rt_sigaction(). It
// is preferred to the more modern version because gdb knows about
// rt_sigaction() and will start intercepting signals, but it seems to
// ignore sigaction().
struct cyg_hal_sys_sigaction {
    void        (*hal_handler)(int);
    long        hal_mask;
    int         hal_flags;
    void        (*hal_restorer)(void);
};

However, looking in /usr/include/bits/sigaction.h

struct sigaction
  {
    /* Signal handler.  */
#ifdef __USE_POSIX199309
    union
      {
	/* Used if SA_SIGINFO is not set.  */
	__sighandler_t sa_handler;
	/* Used if SA_SIGINFO is set.  */
	void (*sa_sigaction) (int, siginfo_t *, void *);
      }
    __sigaction_handler;
# define sa_handler	__sigaction_handler.sa_handler
# define sa_sigaction	__sigaction_handler.sa_sigaction
#else
    __sighandler_t sa_handler;
#endif

    /* Additional set of signals to be blocked.  */
    __sigset_t sa_mask;

    /* Special flags.  */
    int sa_flags;

    /* Restore handler.  */
    void (*sa_restorer) (void);
  };

Where, and this is the interesting bit...
/usr/include/bits/sigset.h says

# define _SIGSET_NWORDS	(1024 / (8 * sizeof (unsigned long int)))
typedef struct
  {
    unsigned long int __val[_SIGSET_NWORDS];
  } __sigset_t;


ie. Ecos thinks sa_mask is one int, linux thinks it's 32 int's in a row. If a sigaction is near the edge of available VM a call to sigaction crashes, otherwise it magically (sort of) works.





John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand


Somewhere on the edge of a Galaxy, one of literally billions of such galaxies, is a sun, one of literally billions of suns in that galaxy.

Orbiting that sun is a small rock 330000 times smaller than that
sun.

This rock is  covered by a very very thin scum  of life. (Think 6000km
of rock followed by a meter or so of biomass.)

Amongst the millions of species in that scum are many hundreds of
thousands of types beetle and a mere handful of primates.

Surprisingly enough, this email does not originate from a beetle.

It originates from just one of the 6 billion vastly outnumbered humans.

I trust you will keep this perspective and context in mind when
reacting to this email.

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