[haiku-development] Re: [RFC] sigaction SA_SIGINFO support
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 12 Aug 2008 18:10:59 +0200
On 2008-08-12 at 13:27:50 [+0200], Andreas Färber <andreas.faerber@xxxxxx>
wrote:
>
> Am 12.08.2008 um 12:54 schrieb Ingo Weinhold:
>
> >
> > On 2008-08-12 at 01:37:49 [+0200], Andreas Färber <andreas.faerber@xxxxxx
> > >
> > wrote:
> >>
> >> Attached is a patch which attempts to add support for POSIX-style
> >> signal handlers that provide extended information on the signal and
> >> context. [...]
> >>
> >> This is still work in progress, I'm posting it to check whether I'm
> >> on
> >> the right track there. I've tested it in a gcc4 image with ftp and
> >> vim. Not yet tested with the signal test apps, not in a gcc2 image
> >> and
> >> not the new code path. I have however checked (via panic) that the
> >> new
> >> codepath was not taken by accident.
> >
> > Looks good so far.
>
> Good to hear, thanks.
>
> >
> >> What is still missing is a lot of
> >> info in the siginfo_t struct, which isn't currently available (new
> >> SA_SIGINFO code path only). I was thinking we could use the siginfo_t
> >> as argument to arch_setup_signal_frame maybe, to get at that data.
> >
> > That wouldn't help, since some info simply isn't available (like the
> > sender). We'd have to add realtime signal support to get those.
>
> I was hoping more to get at the signal code (i.e. SEGV_ACCERR for
> SIGSEGV)
The information whether the cause is a SEGV_ACCERR or SEGV_MAPERR or simply
a signal sent by another thread is not available at this point anymore. The
reason is that this is the time the signal is handled, not the time the
signal occurred, and all we store for a signal is a bit in a bit mask that
the signal has occurred. We could probably hack that in somehow, but the
clean solution is to implement realtime signals. That is when a signal is
sent, an object that contains all the additional information associated with
the signal has to be created and appended to a (to be added) signal queue
per thread. While that is all not overly complicated it is nevertheless
quite a bit of work.
> and the address where the SIGSEGV occurred. At least the
> latter should be available, so would you prefer additional, e.g.,
> uint32 arguments over a single siginfo_t? I don't see another way
> currently.
The address of the faulting instruction (if it was a segmentation fault at
all and not just a signal sent by some thread) is simply the eip that is
available from the iframe.
CU, Ingo
Other related posts:
