Messages in this thread | | | Date | Fri, 20 Aug 1999 16:45:00 -0700 | From | (Steve Jankowski) | Subject | siginfo->si_addr for SIGSEGV |
| |
[ I'm not on the linux-kernel mailing list, please Cc steve@activesw.com on any responses. Thanks. ]
I'm trying to port some code that uses SA_SIGINFO to get the address of a memory fault in a SIGSEGV handler. However, I found that si_addr (of siginfo_t) is always 0.
I checked the 2.2.x and 2.3.13 source and found that SA_SIGINFO is not totally implemented. In the platform specific code (arch/xxx/mm/fault.c) I found that the fault address is stuck in the task_struct and force_sig() (kernel/signal.c) is called. force_sig() calls force_sig_info() and passes '1' for (siginfo_t *), thus causing send_sig_info() to assume there isn't a siginfo_t available for the signal. Hmm... actually, it seems like send_sig_info() totally ignores its 'info' argument unless dealing with a real-time signal.
(Oddly, the m68k arch completes a siginfo_t and passes it to force_sig_info(). But to no avail since it's ignored.)
There's a comment in kernel/signal.c to the effect that it would be nice to implement SA_SIGINFO. I'd give it a go myself, but I'm not a kernel programmer, and the comment implies it's not so trivial:
/* XXX: As an extension, support queueing exactly one non-rt signal if SA_SIGINFO is set, so that we can get more detailed information about the cause of the signal. */
I guess the implication is that a signal may be queued more than once and thus signal detail would be unavailable or inaccurate?
So, my port is basically non-starter without si_addr for SIGSEGV. Getting the port done is critical as it will allow me to work at home, away from the free Cokes and Power Bars in the break room... wait, I sense danger.
Cheers,
Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |