This patch clears up the wording of the first part of the BUGS section
of the sigaction.2 man page.
Currently, it is very unclear when exactly the bug can occur, and
there is no example, which I aim to fix.

I also attach the source code of a C program that, when run on an x86
Linux computer, shows that my example behaves like I say it does. The
code runs the int instruction for each value from 0 to 255 with all
registers set to 0 to show what is contained in the siginfo_t returned
to the signal handler afterwards.

The program is based on the attachment to bug 205831 on the kernel
Bugzilla, which first dealt with this issue, you can find that bug
report here: https://bugzilla.kernel.org/show_bug.cgi?id=205831. The
text of my contribution is also partially based on the BUGS section of
the signal.2 man page.

Signed-off-by: Mikołaj Kołek <redacted>
---
 man/man2/sigaction.2 | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/man/man2/sigaction.2 b/man/man2/sigaction.2
index df8826e71..2b797355b 100644
--- a/man/man2/sigaction.2
+++ b/man/man2/sigaction.2

@@ -1129,13 +1129,29 @@ .SS Undocumented
 See the relevant Linux kernel sources for details.
 This use is obsolete now.
 .SH BUGS
-When delivering a signal with a
+When delivering a signal resulting from a hardware exception with a
 .B SA_SIGINFO
 handler,
 the kernel does not always provide meaningful values
 for all of the fields of the
 .I siginfo_t
 that are relevant for that signal.
+For example, when the x86
+.I int
+instruction is called with a forbidden argument
+(any number other than 3 or 128), a
+.BR SIGSEGV
+signal is delivered, but the
+.I siginfo_t
+passed to the signal handler has all its fields besides
+.I si_signo
+and
+.I si_code
+set to zero, even if other fields should be set (as an example,
+.I si_addr
+should be non-zero for all
+.BR SIGSEGV
+signals).
 .P
 Up to and including Linux 2.6.13, specifying
 .B SA_NODEFER
--

2.46.0