This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/13440] New: cast.exp fails on s390x umod cast in (kernel) begin probe
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Sat, 26 Nov 2011 14:21:26 +0000
- Subject: [Bug runtime/13440] New: cast.exp fails on s390x umod cast in (kernel) begin probe
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=13440
Bug #: 13440
Summary: cast.exp fails on s390x umod cast in (kernel) begin
probe
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: runtime
AssignedTo: systemtap@sourceware.org
ReportedBy: mjw@redhat.com
Classification: Unclassified
cast.exp will fail on s390x with a ERROR: kernel read fault at
0x000000004128dbba (addr) near identifier '@cast' at
.../testsuite/systemtap.base/cast.stp:37:17
This is because that line does:
cast_data = @cast(get_sockaddr(data), "sockaddr", "<sys/socket.h>")->sa_data[0]
make_typequery will see the "<sys/socket.h>" and assume this is a user mode
cast and generates a umod, not a kmod. dwarf_cast_query::handle_query_module()
sees the umod and installs the uderef for user mode address access. This will
then fail (correctly?) fail to access the address as user data.
We could fix the test by using "kernel<linux/socket.h>" which will generate a
kmod instead of a umod. But the comment in the testcase seems to assume you can
use a umod @cast in a begin probe.
I think we should not try to provide user space access in begin/end probes
through casts and the test should be rewritten if it wants to also test umod
casts.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.