[Bug kprobes/22772] missing kernel/module debuginfo for custom lt kernel

["dsmith at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #4 from David Smith <dsmith at redhat dot com> ---
(In reply to ocket8888 from comment #0)
> Created attachment 10770 [details]
> kernel configuration
> 
> I've been trying (and failing) to get systemtap to work on my CentOS machine.
> ```
>     $ uname -a
>     Linux ipcdn-cache-51.cdnlab.comcast.net 4.9.70-1.el7.centos.x86_64 #1
> SMP Thu Feb 1 15:34:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>     $ cat /etc/centos-release```
>     CentOS Linux release 7.4.1708 (Core)
>     $ stap --version
>     Systemtap translator/driver (version 3.1/0.168, rpm 3.1-5.el7_4)
> Copyright (C) 2005-2017 Red Hat, Inc. and others
> This is free software; see the source for copying conditions.
> tested kernel versions: 2.6.18 ... 4.10-rc8
> enabled features: AVAHI BOOST_STRING_REF DYNINST JAVA PYTHON2 LIBRPM
> LIBSQLITE3 LIBVIRT LIBXML2 NLS NSS READLINE
> ```
> 
> I'm attaching the configuration used to build the kernel, note that it
> follows the configuration specified in the FAQ (Q2). When I run the test
> command `stap -ve 'probe vfs.read{exit()}` it outputs
> 
> ```
>     Pass 1: parsed user script and 529 library scripts using
> 378212virt/192180res/6484shr/188296data kb, in 2030usr/40sys/2078real ms.
>     semantic error: while resolving probe point: identifier 'kernel' at
> /usr/share/systemtap/tapset/linux/vfs.stp:915:18
>         source: probe vfs.read = kernel.function("vfs_read")
>                                  ^
> 
>     semantic error: missing x86_64 kernel/module debuginfo [man
> warning::debuginfo] under '/lib/modules/4.9.70-1.el7.centos.x86_64/build'

Interesting. I'm betting the '-lt' tag is going to show up in the filenames
installed by one (or more) of the kernel-lt packages. Pay close attention to
the following packages: kernel-lt, kernel-lt-debuginfo, and kernel-lt-devel.
Does '-lt' show up in any of the filenames from those packages?

If so, an semi-easy workaround here would be to create a symbolic link from the
path systemtap expects to the path containing '-lt'.

If I'm right, I'm not sure what the best solution to this problem would be in
systemtap to automatically recognize the '-lt' kernels.

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