Date: Thu, 22 Oct 1998 02:01:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: hackers@FreeBSD.ORG Subject: Re: Handling page faults in user space ? Message-ID: <199810220201.TAA13283@usr01.primenet.com> In-Reply-To: <199810210744.IAA09732@labinfo.iet.unipi.it> from "Luigi Rizzo" at Oct 21, 98 08:44:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> i was wondering how to handle page faults/segment violations in user
> space. Looking at mmap, signal and friends it looks like it is almost
> possible.
>
> E.g. take the following program segment:
>
> int *p = 0xdeadbeef ;
>
> sig_t
> handle_sigsegv(int i)
> {
> fprintf(stderr, "got sigsegv\n");
> mmap(p, 0x1000, PROT_READ, MAP_ANON, -1, 0);
> }
>
> main()
> {
> int a;
> signal(SIGSEGV, handle_sigsegv);
>
> a = *p ; /* this results in a SIGSEGV being posted */
> fprintf(stderr, "ahhh....\n");
> }
>
> causes first a fault and then the faulting instruction is restarted and
> produces the right output. What is missing is how to know, in the
> signal handler, the fault virtual address and maybe IP associated to
> the faulting instruction.
>
> Ideas anyone ?
The Go Solo 2 CDROM says that siginfo_t SHALL contain, minimally, the
following fields:
typedef struct {
int si_signo; /* signal number*/
int si_errno; /* if non-zero, there is an errno
* associated with this signal, as
* defined in <errno.h>
*/
int si_code; /* signal code*/
pid_t si_pid; /* sending process ID*/
uid_t si_uid; /* real user ID of sending process*/
void *si_addr; /* address of faulting instruction*/
int si_status; /* exit value or signal*/
long si_band; /* band event for SIGPOLL*/
union sigval si_value; /* signal value*/
} siginfo_t;
For the relevent signals, the values si_code can take on are:
SIGSEGV
SEGV_MAPERR /* address not mapped to object*/
SEGV_ACCERR /* invalid permissions for mapped object*/
SIGBUS
BUS_ADRALN /* invalid address alignment*/
BUS_ADRERR /* non-existant physical address*/
BUS_OBJERR /* object specific hardware error*/
It also states that, in addition, the following signal-specific
information WILL be available:
SIGILL
SIGFPE si_addr /* address of faulting instruction*/
SIGSEGV
SIGBUS si_addr /* address of faulting memory reference*/
SIGCHLD si_pid /* child process ID*/
si_status /* exit value or signal*/
si_uid /* real user ID of the process that sent
* the signal
*/
SIGPOLL si_band /* band event for POLL_IN, POLL_OUT, or
* POLL_MSG
*/
I think you are looking for si_addr, and that you can't know the IP,
since it overloads si_addr, but knowing the fault address is good
enough to handle the fault.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810220201.TAA13283>