siginfo->si_addr for SIGSEGV

Steve Jankowski (steve@broccoli.activesw.com)
Fri, 20 Aug 1999 16:45:00 -0700


[ 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/