This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: cli/1056: divide by zero hangs gdb
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 28 Aug 2003 08:08:00 -0000
- Subject: Re: cli/1056: divide by zero hangs gdb
- Reply-to: Michael Elizabeth Chastain <mec at shout dot net>
The following reply was made to PR cli/1056; it has been noted by GNATS.
From: Michael Elizabeth Chastain <mec@shout.net>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: cli/1056: divide by zero hangs gdb
Date: Thu, 28 Aug 2003 04:07:22 -0400
I tried messing with handle_sigfpe:
/* old */
static void
handle_sigfpe (int sig)
{
mark_async_signal_handler_wrapper (sigfpe_token);
signal (sig, handle_sigfpe);
}
/* new */
static void
handle_sigfpe (int sig)
{
signal (sig, handle_sigfpe);
error ("Erroneous arithmetic operation.");
}
Works for me. But I don't know if it's architecturally okay to
call 'error' from a signal handler. We really have little choice,
though. We can either:
. not have a signal handler for handle_sigfpe
. longjmp out of the signal handler
. do some nasty os-specific and machine-instruction-specific code reading
to advance the program counter past the faulty instruction
I need to talk to someone about these async signal handler wrapper
thingies and why gdb can't use one for SIGFPE.
Michael C