[Bug documentation/11554] New: Document SYSTEMTAP_DEBUGINFO_PATH better

[Bug documentation/11554] New: Document SYSTEMTAP_DEBUGINFO_PATH better

[jkenisto at us dot ibm dot com]

From time to time, a stap user comes to me with the following problem.  He (or
she) is trying to debug a distro-provided kernel.  He's downloaded the debuginfo
rpm, but he doesn't know how to tell stap where to find the debuginfo.  And even
though I've been using stap for years, neither do I.

I know that there's probably some way to set the SYSTEMTAP_DEBUGINFO_PATH
environment variable to solve his problem, but the stap(1) man page (which is
the only place I see SYSTEMTAP_DEBUGINFO_PATH mentioned) is almost no help here.
 Even consulting the stap source is no help, because the debuginfo search
algorithm seems to be buried in the bowels of elfutils.

I usually end up advising them to do what I do, which is to build a new kernel
with -g and point /boot/vmlinux-<version> at it.  But that's often not an option.

So could somebody who knows this stuff please document it clearly?  Specifically...
1. What does stap expect the kernel debuginfo file to be called?
2. How do you tell stap to find it in directory D?
3. What about debuginfo for kernel modules?
4. What about debuginfo for user programs?
5. What about debuginfo for libraries?

-- 
           Summary: Document SYSTEMTAP_DEBUGINFO_PATH better
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: documentation
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: jkenisto at us dot ibm dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11554

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

[Bug documentation/11554] Document SYSTEMTAP_DEBUGINFO_PATH better

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-04-28 18:30 -------
See also bug #6562.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11554

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

[Bug documentation/11554] Document SYSTEMTAP_DEBUGINFO_PATH better

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2010-04-28 18:44 -------
(In reply to comment #1)
> See also bug #6562.

Yeah, I've looked at #6562, and it's related.  But even that doesn't contain the
info I'm looking for.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11554

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

[Bug documentation/11554] Document SYSTEMTAP_DEBUGINFO_PATH better

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2010-05-24 15:53 -------
In response to another perplexed user, Srikar Dronamraju wrote:
-----
From my experience stap looks for debuginfo files in this order.
As soon as it finds a vmlinux file, it stops searching even if that
vmlinux file is not debug file.

The directory containing vmlinux can also specified by using 
SYSTEMTAP_DEBUGINFO_PATH environmental variable.  [How?  Jim]

/boot/vmlinux-`uname -r`
/boot/.debug/vmlinux-`uname -r`
/usr/lib/debug/boot/vmlinux-`uname -r`
/boot/vmlinux-`uname -r`.debug
/boot/.debug/vmlinux-`uname -r`.debug
/usr/lib/debug/boot/`uname -r`5.1snap2.debug
/lib/modules/`uname -r`/vmlinux
/lib/modules/`uname -r`/vmlinux.debug
/lib/modules/`uname -r`/.debug/vmlinux.debug
/usr/lib/debug/lib/modules/`uname -r`/vmlinux.debug
-----
How did you determine this, Srikar?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11554

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

[Bug documentation/11554] Document SYSTEMTAP_DEBUGINFO_PATH better

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2010-05-25 07:52 -------
> 
> The directory containing vmlinux can also specified by using 
> SYSTEMTAP_DEBUGINFO_PATH environmental variable.  [How?  Jim]

looks like systemtap looks for boot/vmlinux-`uname -r` and boot/vmlinux-`uname
-r`.debug file and lib/modules/`uname -r`/vmlinux files under the
SYSTEMTAP_DEBUGINFO_PATH.

> 
> /boot/vmlinux-`uname -r`
> /boot/.debug/vmlinux-`uname -r`
> /usr/lib/debug/boot/vmlinux-`uname -r`
> /boot/vmlinux-`uname -r`.debug
> /boot/.debug/vmlinux-`uname -r`.debug
> /usr/lib/debug/boot/`uname -r`5.1snap2.debug
> /lib/modules/`uname -r`/vmlinux
> /lib/modules/`uname -r`/vmlinux.debug
> /lib/modules/`uname -r`/.debug/vmlinux.debug
> /usr/lib/debug/lib/modules/`uname -r`/vmlinux.debug
> -----
> How did you determine this, Srikar?

This info is from "strace -e open" run on stap.

I agree we should be documenting it at some place.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11554

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

[Bug documentation/11554] Document SYSTEMTAP_DEBUGINFO_PATH better

[lberk at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11554

Lukas Berk <lberk at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |lberk at redhat dot com
         Resolution|                            |FIXED

--- Comment #5 from Lukas Berk <lberk at redhat dot com> 2010-10-14 21:24:31 UTC ---
commit:   d7cec9a..e9d024d

I've added further documentation to the stappaths.7 man page about
SYSTEMTAP_DEBUGINFO_PATH.  Where stap looks for vmlinux, how to set the
environment variable to point to a different directory, and where to find more
information about user space application debuginfo

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.