This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/20618] Cannot get the real syscall return code value
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 19 Sep 2016 15:43:49 +0000
- Subject: [Bug tapsets/20618] Cannot get the real syscall return code value
- Auto-submitted: auto-generated
- References: <bug-20618-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20618
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |codonell at redhat dot com,
| |fche at redhat dot com
Resolution|--- |WORKSFORME
--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
> We couldn't find in any part of the documentation that returnval() or the
> syscall return value will be replaced with the errno value [...]
It turns out that this is an artefact of how linux system calls
work. A positive/zero return value is success, a negative
return value usually is an error code that the glibc runtime will
shift into the global 'errno'. At the low systemtap level, the
negative errno -is- the genuine return value from the syscall.
Unfortunately, we don't have convenient probes at the glibc level
to observe the C-level aftereffects properly. There is a glibc
RFE open (for quite some time now) for them to insert some sys/sdt.h
markers, so that stap could present the cooked results properly.
(RHers, see also https://bugzilla.redhat.com/show_bug.cgi?id=742034 .)
--
You are receiving this mail because:
You are the assignee for the bug.