Subject: Re: Return addresses from trap signals
To: Jason R Thorpe <firstname.lastname@example.org>
From: Ben Harris <email@example.com>
Date: 03/06/2001 01:06:09
On Mon, 5 Mar 2001, Jason R Thorpe wrote:
> On Tue, Mar 06, 2001 at 12:33:21AM +0000, Ben Harris wrote:
> > What should happen if a handler for a trap signal (SIGILL, SIGSYS,
> > SIGSEGV, SIGTRAP) returns, or if the signal's ignored? Should the failed
> > instruction be retried, or should the machine skip on to the next
> > instruction? Does this depend on which signal it is? I'm trying to work
> > out what the right value to put in trapframes on ARM systems is, and
> > following what a sigcontext will need might be as good an approach as any.
> You only get into the machdep code you're concerned about if there's
> actually a handler for the signal...
Actually the code I'm currently concerned about is what _calls_
trapsignal(), so it's always involved. If the signal's being ignored then
trapsignal() won't do much and the trap handler will return to the PC it
just left in the trapframe.
> and if the handler returns, I'd
> say that you restart the insn. (There are some user-level debugging
> allocators and garbage-collectors that abuse SIGSEGV, and expect that
> you can restart...)
That's OK for SIGSEGV. I think SIGSYS will turn out OK anyway (it's not
triggered by trapsignal(), but by psignal(), so the syscall handler will
update PC if necessary before the sigcontext is generated). I'm not sure
what the results of ignoring SIGILL should be, but I suspect most people
would think doing so was silly.
Hmm. How about SIGFPE?
Ben Harris <firstname.lastname@example.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>