Differential D25777 Diff 75012 share/man/man3/siginfo.3

Changeset View

Standalone View

share/man/man3/siginfo.3

	Show First 20 Lines • Show All 62 Lines • ▼ Show 20 Lines
	signal code			signal code
	.It Vt union sigval Ta Va si_value Ta			.It Vt union sigval Ta Va si_value Ta
	signal value			signal value
	.It Vt pid_t Ta Va si_pid Ta			.It Vt pid_t Ta Va si_pid Ta
	sending process ID			sending process ID
	.It Vt uid_t Ta Va si_uid Ta			.It Vt uid_t Ta Va si_uid Ta
	sending process's real user ID			sending process's real user ID
	.It Vt void Ta Va *si_addr Ta			.It Vt void Ta Va *si_addr Ta
	address of faulting instruction			virtual address
	.It Vt int Ta Va si_status Ta			.It Vt int Ta Va si_status Ta
	exit value or signal			exit value or signal
	.It Vt long Ta Va si_band Ta			.It Vt long Ta Va si_band Ta
	band event for			band event for
	.Dv SIGPOLL			.Dv SIGPOLL
	.It Vt int Ta Va si_trapno Ta			.It Vt int Ta Va si_trapno Ta
	machine trap code			machine trap code
	.It Vt int Ta Va si_timerid Ta			.It Vt int Ta Va si_timerid Ta
	▲ Show 20 Lines • Show All 123 Lines • ▼ Show 20 Lines
	signal generated by arrival of a message on an empty message queue			signal generated by arrival of a message on an empty message queue
	.It Ta Dv SI_KERNEL Ta			.It Ta Dv SI_KERNEL Ta
	signal generated by miscellaneous parts of the kernel			signal generated by miscellaneous parts of the kernel
	.It Ta Dv SI_LWP Ta			.It Ta Dv SI_LWP Ta
	signal sent by			signal sent by
	.Xr pthread_kill 3			.Xr pthread_kill 3
	.El			.El
	.Pp			.Pp
				For synchronous signals,
				.Va si_addr
				is generally set to the address of the faulting instruction.
				However, sychronous signals raised by a faulting memory access such as
				kibUnsubmitted Done Inline Actions typo missed 'n' in syNchronous kib: typo missed 'n' in syNchronous
				.Dv SIGSEGV
				and
				.Dv SIGBUS
				may report the address of the faulting memory access in
				.Va si_addr
				if it is available.
				kibUnsubmitted Not Done Inline Actions it reads as 'if si_addr is available'. Might be, 'if hardware provides it'. kib: it reads as 'if si_addr is available'. Might be, 'if hardware provides it'.
				jhbAuthorUnsubmitted Done Inline Actions I moved the "if available" earlier to try to make it less ambiguous. jhb: I moved the "if available" earlier to try to make it less ambiguous.
				.Pp
				Sychronous signals raised in response to an instruction may set
				kibUnsubmitted Done Inline Actions still 'in response to an instruction' is confusing. Either mark that as explanation, i.e. `Synchronous signals, i.e. signals raised in response to faulting instruction`. Or remove that part at all. Doesn't we always set si_trapno, after you commits ? kib: still 'in response to an instruction' is confusing. Either mark that as explanation, i.e.
				jhbAuthorUnsubmitted Done Inline Actions Oh, yes, just failed to fix both places. Hmm, I guess we do always set si_trapno now. jhb: Oh, yes, just failed to fix both places. Hmm, I guess we do always set si_trapno now.
				.Va si_trapno
				to a machine-dependent trap number.
				kibUnsubmitted Not Done Inline Actions I am confused by your terminology there. Synchronous signals are always sent due to an instruction action, even it the instruction generated a trap/fault that was caused by invalid memory access. After some re-reading, I think you are trying to state that if there was a memory access to specific address that faulted, the address is reported in si_addr, otherwise the address of faulting instruction is reported in si_addr. Even this is not completely true, and you are right that you used 'may' when described that SIGSEGV/SIGBUS may report the faulting address, but could not (e.g. on x86 page faults do, but segmentation faults do not). I believe I was confused by 'in response to an instruction' part. kib: I am confused by your terminology there. Synchronous signals are always sent due to an…
				jhbAuthorUnsubmitted Done Inline Actions I'm trying to distinguish from async signals sent via kill(2), etc. However, perhaps synchronous already covers this and I can just drop the problematic "in response to an instruction". I did use "may" to mean "you have to read the trap handler for the arch in question to determine what you get". Curiously, the POSIX (open group) description of si_addr says that SIGSEGV/SIGBUS always report a faulting memory reference: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html jhb: I'm trying to distinguish from async signals sent via kill(2), etc. However, perhaps…
				kibUnsubmitted Not Done Inline Actions I always interpreted 'synchronous signals' as system reaction to traps. I.e., in our terms, results of trapsignal(). Indeed, we are not compliant with POSIX for SIGSEGV/SIGBUS, but it really reduces to two cases: 1. For non-canonical addresses and SIGSEGV, we indeed do not report the faulting address, because hardware does not provide the value. 2. For segmentation faults, the faulting address is not representable in the uintptr_t. kib: I always interpreted 'synchronous signals' as system reaction to traps. I.e., in our terms…
				.Pp
	In addition, the following signal-specific information is available:			In addition, the following signal-specific information is available:
	.Bl -column ".Dv SIGPOLL" ".Dv CLD_CONTINUED"			.Bl -column ".Dv SIGPOLL" ".Dv CLD_CONTINUED"
	.It Sy Signal Ta Sy Member Ta Sy Value			.It Sy Signal Ta Sy Member Ta Sy Value
	.It Dv SIGILL Ta Va si_addr Ta
	address of faulting instruction
	.It Ta Va si_trapno Ta
	machine dependent of trap code
	.It Dv SIGFPE Ta Va si_addr Ta
	address of faulting instruction
	.It Ta Va si_trapno Ta
	machine dependent of trap code
	.It Dv SIGSEGV Ta Va si_addr Ta
	address of faulting memory reference
	.It Ta Va si_trapno Ta
	machine dependent of trap code
	.It Dv SIGBUS Ta Va si_addr Ta
	address of faulting instruction
	.It Ta Va si_trapno Ta
	machine dependent of trap code
	.It Dv SIGCHLD Ta Va si_pid Ta			.It Dv SIGCHLD Ta Va si_pid Ta
	child process ID			child process ID
	.It Ta Va si_status Ta			.It Ta Va si_status Ta
	exit value or signal; if			exit value or signal; if
	.Va si_code			.Va si_code
	is equal to			is equal to
	.Dv CLD_EXITED ,			.Dv CLD_EXITED ,
	then it is equal to the exit value of the child process, otherwise,			then it is equal to the exit value of the child process, otherwise,
	▲ Show 20 Lines • Show All 107 Lines • Show Last 20 Lines