public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: James Y Knight <foom@fuhm.net>
To: Eugeniy Meshcheryakov <eugen@debian.org>
Cc: systemtap@sourceware.org
Subject: Re: Troubles with debug info, using systemtap on debian.
Date: Tue, 10 Nov 2009 18:38:00 -0000	[thread overview]
Message-ID: <B1AE0BF2-60F8-46CE-BA42-C9EF460B1814@fuhm.net> (raw)
In-Reply-To: <20091110093254.GA3190@localhost.localdomain>

On Nov 10, 2009, at 4:32 AM, Eugeniy Meshcheryakov wrote:
>> probe module("autofs4").function("autofs4_fill_super") {}
> I never saw systemtap segfaulting. I do not have autofs4 module, but i
> tried with snd module and it works. What version of
> systemtap/libelf1/libdw1 do you use?

After seeing the segfaults, I compiled both systemtap and elfutils  
from latest git head, as of yesterday. Same segfaults. Before that, I  
was using:
systemtap 1.0-2
libelf/etc 0.143-1

The segfaults only occur if the installed module is stripped of debug  
data (which it usually is), and if the debug data itself is stripped  
of code. That is the case with the files debian's kernel-package  
installs into /usr/lib/debug/*.ko, but I'm led to believe is not the  
case with the files that Fedora installs into /usr/lib/debug/*.ko.debug.

Unless something *further* strange is going on in my environment,  
anyone should be able to reproduce by:
1) removing the symlink to your kernel build dir (rm /lib/modules/ 
$VERS/build): renaming is not enough, systemtap still finds it!
2) ensuring that the debug info in /usr/lib/debug is stripped of code  
with objcopy --only-keep-debug.
3) ensuring the kernel modules in /lib/modules/$VERS are stripped of  
debug info.

I'd certainly be interested if people can't reproduce this, so I can  
look further to try to figure out what else might be a triggering  
factor...

>> 3) The debian kernel's debuginfo does "objcopy --only-keep-
>> debug"...That seems like it shouldn't cause systemtap to blow up,
>> but it does. I guess that's a known bug?
> No it is not. At least not for me.

When I was discussing this on IRC "przemoc86" mentioned that debuginfo  
stripped of code might not be currently supported. In any case, a  
segfault seems poor, whether or not it's supposed to be supported. :)

James

  parent reply	other threads:[~2009-11-10 18:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10  1:18 James Y Knight
2009-11-10  9:35 ` Eugeniy Meshcheryakov
2009-11-10 10:19   ` Eugeniy Meshcheryakov
2009-11-10 18:07   ` Frank Ch. Eigler
2009-11-10 18:24     ` James Y Knight
2009-11-10 18:38   ` James Y Knight [this message]
2009-11-11  9:41     ` Eugeniy Meshcheryakov
2009-11-11  9:50       ` Eugeniy Meshcheryakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B1AE0BF2-60F8-46CE-BA42-C9EF460B1814@fuhm.net \
    --to=foom@fuhm.net \
    --cc=eugen@debian.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).