Cam, > > a. siginfo_t is properly delivered to 32-bit userspace from a 32-bit > > kernel. If it doesn't, please show me the example code, kernel config, > > and hardware used to run the test. This has always worked. > > > > Well, I'm not sure how long is meant by always, but lets forget about > the past for the moment. Right now on paer I can get the address in > ((siginfo_t *)code)->si_ptr > where the handler is defined as > void > memprotect_handler(int sig, long code, void *scp, char *addr) > and setup with SA_RESTART and SA_SIGINFO. On most machines its under > ((siginfo_t *)code)->si_addr > but not on paer. I can show you a gdb trace if you need.
si_ptr is only valid for POSIX real-time signals, don't use that. paer is a 64-bit box running 2.4.23-pa5, and thus does not have the fixes required. The fact that si_ptr works is a *complete* fluke, the kernel has shifted all values in the structure. You are really reading a 64-bit version of the structure. Please apply pressure to have paer updated to a new 2.6.x kernel :) > Thanks for this jog. This has been on my todo list for sometime now. > I've just implemented a runtime test for the fault recovery > mechanism. I'm not checking kernel versions per se, just the compile > time determined code snippet for recovering the fault address on the > runtime kernel. Here's the outline: It looks fine, you just can't run that code on a 64-bit box without a 2.6.1 or newer kernel from cvs.parisc-linux.org. c.