From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sa_sigaction signal handler: third parameter?
Date: Fri, 7 Sep 2001 02:38:33 +0100 [thread overview]
Message-ID: <20010907023833.B7329@kushida.degree2.com> (raw)
In-Reply-To: <3B95F745.A1476AFD@axis.com>
In-Reply-To: <3B95F745.A1476AFD@axis.com>; from orjan.friberg@axis.com on Wed, Sep 05, 2001 at 11:58:29AM +0200
Orjan Friberg wrote:
> I'm trying to make life easier for a user-defined SIGSEGV handler, the
> sa_sigaction one with 3 parameters. The second parameter, the siginfo_t
> * one, is there. Problem is, I would like to pass on additional
> information to the signal handler, more specifically information about
> whether there was a protection fault, read/write etc. I've looked at
> some of the other ports (I'm working on the CRIS port BTW), and for
> example the i386 has fields in the task and sigcontext structs to keep
> this sort of information.
>
> Question is how to pass this information on to the signal handler.
> Looking at the code, it seems the third parameter (void *) is being used
> to send a ucontext_t * in (at least) the arm and mips cases. I followed
> a lot of threads in the archive, but couldn't find one that adressed
> what this third parameter is actually meant to be used for. Obviously,
> sending a ucontext would solve my problem, since it contains the
> sigcontext struct. Is there a Right Way to do it?
Whether or not there was a protection fault is indicated with
SEGV_MAPERR vs. SEGV_ACCERR. Unfortunately, the siginfo_t doesn't have
any place to indicate whether it's a read or a write fault. *How could
they have left that out?*
The Right Way, IMHO, would be to find some acceptable,
standard-compatible way to get the read/write flag into the siginfo_t.
cheers,
-- Jamie
prev parent reply other threads:[~2001-09-07 13:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-05 9:58 sa_sigaction signal handler: third parameter? Orjan Friberg
2001-09-07 1:38 ` Jamie Lokier [this message]
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=20010907023833.B7329@kushida.degree2.com \
--to=lk@tantalophile.demon.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=orjan.friberg@axis.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.