[Bug runtime/29095] New: stap -r dir does not work

[Bug runtime/29095] New: stap -r dir does not work

[cppcoffee at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29095

            Bug ID: 29095
           Summary: stap -r dir does not work
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: cppcoffee at gmail dot com
  Target Milestone: ---

I compiled using git://sourceware.org/git/systemtap.git master,
then cp -ar  /usr/src/kernels/3.10.0-1160.62.1.el7.x86_64 
/tmp/example/kernel-copy,
followed by stap -r /tmp/example/kernel-copy 
and get the error "Semantic error: while parsing probe points: identifier
'kernel' is at test.stp:1:7"

I see that /lib/modules/3.10.0-1160.62.1.el7.x86_64/build is a soft link to
/usr/src/kernels/3.10.0-1160.62.1.el7.x86_64.

Try using stap -r /usr/src/kernels/3.10.0-1160.62.1.el7.x86_64 also gives the
same error,
but stap -r /lib/modules/3.10.0-1160.62.1.el7.x86_64/build is fine.
why does the difference in path cause one to work and one not to work?

# ll /lib/modules/3.10.0-1160.62.1.el7.x86_64/build
lrwxrwxrwx 1 root root 45 Apr 25 22:47
/lib/modules/3.10.0-1160.62.1.el7.x86_64/build ->
/usr/src/kernels/3.10.0-1160.62.1.el7.x86_64/


Problem reproduction steps:
compile systemtap:
# git clone git://sourceware.org/git/systemtap.git
# cd systemtap
# ./configure \
    --prefix=/opt/systemtap/ \
    --libexecdir=/opt/systemtap/libexec \
    --disable-docs --disable-publican --with-python3 \
    --without-nss         \
    --without-openssl         \
    --without-avahi         \
    --without-bpf         \
    --without-python2-probes         \
    --without-python3-probes         \
    --disable-refdocs        \
    CC='ccache gcc -fdiagnostics-color=always'        \
    CXX='ccache g++ -fdiagnostics-color=always'


2. test.stp example code:
# cat /tmp/example/test.stp
probe kernel.function("tcp_send_active_reset")
{
    printf("active_reset\n");
}

probe kernel.function("tcp_v4_send_reset")
{
    printf("send_reset\n");
}


4. run stap:

use -r /usr/src/kernels/3.10.0-1160.62.1.el7.x86_64

# /opt/systemtap/bin/stap -v --no-global-var-display -p4 -m tcp_reset_XXXXXXX
--save-uprobes -r /usr/src/kernels/3.10.0-1160.62.1.el7.x86_64 test.stp
Pass 1: parsed user script and 483 library scripts using
223820virt/91644res/2228shr/89852data kb, in 250usr/30sys/282real ms.
semantic error: while resolving probe point: identifier 'kernel' at
test.stp:1:7
        source: probe kernel.function("tcp_send_active_reset")
                      ^


use -r /lib/modules/3.10.0-1160.62.1.el7.x86_64/build

# /opt/systemtap/bin/stap -v --no-global-var-display -p4 -m tcp_reset_XXXXXXX
-r /lib/modules/3.10.0-1160.62.1.el7.x86_64/build --save-uprobes test.stp
Pass 1: parsed user script and 483 library scripts using
223820virt/91640res/2228shr/89852data kb, in 250usr/20sys/277real ms.
Pass 2: analyzed script: 2 probes, 0 functions, 0 embeds, 0 globals using
265824virt/134592res/3056shr/131856data kb, in 510usr/40sys/548real ms.
Pass 3: translated to C into
"/tmp/stapilkFtj/orxray_tcp_reset_fgraph_XXXXXXX_src.c" using
265824virt/134828res/3292shr/131856data kb, in 0usr/0sys/4real ms.
tcp_reset_XXXXXXX.ko
Pass 4: compiled C into "tcp_reset_XXXXXXX.ko" in 930usr/320sys/1061real ms.




# gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

# uname -a
Linux centos7-liuxiaobo 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59
UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# rpm -qa --qf %{name}-%{version}-%{release}.%{arch}\\n | egrep
'systemtap|elfutils|kernel|gcc' | sort
elfutils-0.176-5.el7.x86_64
elfutils-default-yama-scope-0.176-5.el7.noarch
elfutils-devel-0.176-5.el7.x86_64
elfutils-libelf-0.176-5.el7.x86_64
elfutils-libelf-devel-0.176-5.el7.x86_64
elfutils-libs-0.176-5.el7.x86_64
gcc-4.8.5-44.el7.x86_64
gcc-c++-4.8.5-44.el7.x86_64
gcc-gfortran-4.8.5-44.el7.x86_64
kernel-3.10.0-1160.62.1.el7.x86_64
kernel-debuginfo-3.10.0-1160.62.1.el7.x86_64
kernel-debuginfo-common-x86_64-3.10.0-1160.62.1.el7.x86_64
kernel-devel-3.10.0-1160.62.1.el7.x86_64
kernel-headers-3.10.0-1160.62.1.el7.x86_64
kernel-tools-3.10.0-1160.62.1.el7.x86_64
kernel-tools-libs-3.10.0-1160.62.1.el7.x86_64
libgcc-4.8.5-44.el7.x86_64
openresty-elfutils-0.185.2-1.el7.x86_64
openresty-elfutils-devel-0.185.2-1.el7.x86_64
systemtap-4.0-13.el7.x86_64
systemtap-client-4.0-13.el7.x86_64
systemtap-devel-4.0-13.el7.x86_64
systemtap-runtime-4.0-13.el7.x86_64
systemtap-sdt-devel-4.0-13.el7.x86_64

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/29095] stap -r dir does not work

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29095

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
                 CC|                            |fche at redhat dot com
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
stap -r does work; your copy scenario is not capable of creating a complete
kernel-build tree that the -r option expects.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug runtime/29095] stap -r dir does not work

[cppcoffee at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29095

--- Comment #2 from xiaobo liu <cppcoffee at gmail dot com> ---
(In reply to Frank Ch. Eigler from comment #1)
> stap -r does work; your copy scenario is not capable of creating a complete
> kernel-build tree that the -r option expects.

Yes, you're right, I just tested it and I'm sure it's not a stap problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.