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>