Bug 20618 - Cannot get the real syscall return code value
Summary: Cannot get the real syscall return code value
Status: RESOLVED WORKSFORME
Alias: None
Product: systemtap
Classification: Unclassified
Component: tapsets (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-19 02:56 UTC by Gustavo Moreira
Modified: 2016-09-20 04:34 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo Moreira 2016-09-19 02:56:42 UTC
We need to get the syscall return value and the errno separately. However, when for instance, the connect syscall is executed in a non-blocking socket and it returns -1 and errno=115 (EINPROGRESS) all we get in a "probe syscall.*.return" is:
  returnval() = -115
  retstr = "-115 (EINPROGRESS)"

We couldn't find in any part of the documentation that returnval() or the syscall return value will be replaced with the errno value, so I wonder if it's a bug or in any case, how can we get/recover the original syscall return code?
Comment 1 Frank Ch. Eigler 2016-09-19 15:43:49 UTC
> 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 .)
Comment 2 Gustavo Moreira 2016-09-20 04:34:10 UTC
Ouch I see, thank you for the quick response.