systemtap

Relocate ia64-specific _ia64_pipe[01] aux syscall functions.

https://sourceware.org/bugzilla/show_bug.cgi?id=20298 Bug ID: 20298 Summary: the unprivileged_embedded_C.exp testcase needs updating Product: systemtap Version: unspecified ... [More] Status: NEW Severity: normal Priority: P2 Component: testsuite Assignee: systemtap at sourceware dot org Reporter: dsmith at redhat dot com Target Milestone: --- There are at least 2 problems I see with testsuite/systemtap.stress/unprivileged_embedded_C.exp: 1) It only searches tapset functions in tapset/ and tapset/${ARCH}/. It doesn't search tapsets in tapset/linux/ and tapset/linux/${ARCH}/. It needs to be updated for the dyninst/linux tapset directory rearrangement. 2) It gets spurious failures. It assumes that if a tapset function doesn't have any embedded C (i.e. a pure stap script function), a unprivileged user can call it. That isn't the case if that pure stap script function calls a function that is [Less]

https://sourceware.org/bugzilla/show_bug.cgi?id=20297 Bug ID: 20297 Summary: parse error: array size out of range on i686 Product: systemtap Version: unspecified Status: NEW ... [More] Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: mcermak at redhat dot com Target Milestone: --- On i686 kernels I seem to be hitting an unexpected problem with array of size N not being sufficient to accomodate N elements. This seems to work as expected on all other arches AFAICT (incl. also single-abi 32-bit arm). ======= 6.8 S i686 # stap -p2 --poison-cache -ue 'global arr[1] probe oneshot{ arr["a"]=3 }' >/dev/null parse error: array size out of range saw: /usr/local/share/systemtap/tapset/linux/i386/syscall_num.stp EOF 2 parse errors. WARNING: tapset "/usr/local/share/systemtap/tapset/linux/i386/syscall_num.stp" has errors, and will be skipped Number of similar [Less]

Increase the difficulty of semok/autocast14.stp

PR18079: support nested autocast / @defined

https://sourceware.org/bugzilla/show_bug.cgi?id=20288 Bug ID: 20288 Summary: dwfl/elfutils problem when gathering line-record data for *symfile/*symline functions Product: systemtap ... [More] Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: fche at redhat dot com Target Milestone: --- random git stap build running against f22 % ./stap -V Systemtap translator/driver (version 3.1/0.166, commit release-3.0-110-g713029398d38 + changes) % ./stap -p4 -e 'probe process("/bin/ls").function("main") { log(usymfile(0)) }' --vp 0044 [...] dump_unwindsyms /usr/bin/ls index=2 base=0x400000 Found build-id in /usr/bin/ls, length 20, start at 0x400284 WARNING: No debug line data for /usr/bin/ls, no error [...] wait, wha? % rpm -qf /usr/bin/ls coreutils-8.23-11.fc22.x86_64 % rpm -q coreutils-debuginfo coreutils-debugi [Less]

Fix PR20286 by documenting that timer probes can get skipped.

Improve error messages

https://sourceware.org/bugzilla/show_bug.cgi?id=20286 Bug ID: 20286 Summary: probe handlers using hrtimers taking too long Product: systemtap Version: unspecified Status: NEW ... [More] Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: dsmith at redhat dot com Target Milestone: --- When running the full testsuite (in parallel mode, but I'm not sure it matters), I see the following on the console (3.10.0-442.el7.ppc64): [ 6881.740026] hrtimer: interrupt took 3721 ns While that doesn't look too alarming, what it means is that the next timer has already expired because the current timer callback took too long. I'm looking at the source of hrtimer_interrupt() in kernel/time/hrtimer.c. Here's a comment from there: * The next timer was already expired due to: * - tracing * - long lasting callbacks * - being scheduled away when r [Less]

Fix PR20282 by updating loc2c-runtime.h for aarch64.