public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Carter <john.carter@tait.co.nz>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Fedora Core 3 - Ecos synth crashes.
Date: Wed, 04 May 2005 22:08:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.61.0505041151550.10409@parore.tait.co.nz> (raw)

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

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04 22:08 John Carter [this message]
2005-05-04 22:45 ` Bart Veer
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=Pine.LNX.4.61.0505041151550.10409@parore.tait.co.nz \
    --to=john.carter@tait.co.nz \
    --cc=ecos-discuss@ecos.sourceware.org \
    /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).