Bug 5213

Summary:	x86_64 with 2.6.23 kernel seems to miss rt_sigaction for 32-bit code
Product:	systemtap	Reporter:	William Cohen <wcohen>
Component:	runtime	Assignee:	Unassigned <systemtap>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	fche
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:	x86_64	Target:
Build:		Last reconfirmed:

Description William Cohen 2007-10-23 18:00:02 UTC

When running the testsuite on x86_64 with the 2.6.23 kernel the 32-bit kernel
doesn't trigger an action for the rt_sigaction systemcall.

Comment 1 William Cohen 2007-10-23 18:08:04 UTC

Lines of interest in the test output:


rt_signal: rt_sigaction (SIGUSR1, 0x00000000ff8ef17c, 0x0000000000000000, 8) = \
0
rt_signal: rt_sigaction (SIGUSR1, 0x00000000ff8ef17c, 0x0000000000000000, 8) = \
0
rt_signal: rt_sigaction (SIGUSR1, 0x00000000ff8ef17c, 0x0000000000000000, 8) = \
0

--------- EXPECTED and NOT MATCHED ----------
rt_signal: rt_sigaction \(SIGUSR1, {SIG_IGN}, 0x[0]+, 8\) = 0
rt_signal: rt_sigaction \(SIGUSR1, {SIG_DFL}, 0x[0]+, 8\) = 0
rt_signal: rt_sigaction \(SIGUSR1, {[x0-9a-fA-F]+, [^,]+, [x0-9a-fA-F]+, \[SIGA\
LRM\]}, 0x[0]+, 8\) = 0
FAIL: 32-bit rt_signal

Comment 2 Masami Hiramatsu 2008-02-22 22:28:17 UTC

In tapset/syscalls2.stp, syscall.rt_sigaction uses _struct_sigaction_u($act) to
get the signal handler. On the other hand, syscall.rt_sigaction32 doesn't use
that. Thus, it can not get the actual handler address.

Comment 3 Frank Ch. Eigler 2015-11-28 14:16:06 UTC

current tapsets cover rt_sigaction{,32} symmetrically