This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Can't set statement probe in self-built linux-4.4
- From: Chris Dunlop <chris at onthe dot net dot au>
- To: David Smith <dsmith at redhat dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sourceware dot org
- Date: Fri, 15 Jul 2016 03:27:10 +1000
- Subject: Re: Can't set statement probe in self-built linux-4.4
- Authentication-results: sourceware.org; auth=none
- References: <20160630075744.GA3637@onthe.net.au> <y0mk2h6vi3c.fsf@fche.csb> <20160630223410.GB16787@onthe.net.au> <20160701005738.GF3830@redhat.com> <20160701034302.GA23357@onthe.net.au> <20160714160842.GA20289@onthe.net.au> <243a3c91-f699-6dbb-a0e2-778810d08a2e@redhat.com>
On Thu, Jul 14, 2016 at 11:54:56AM -0500, David Smith wrote:
> On 07/14/2016 11:08 AM, Chris Dunlop wrote:
>> On Fri, Jul 01, 2016 at 01:43:02PM +1000, Chris Dunlop wrote:
>>> On Thu, Jun 30, 2016 at 08:57:38PM -0400, Frank Ch. Eigler wrote:
>>>> Something's weird about your -vvvvv trace too; a similar command
>>>> that works here gives a lot more "function cache ...." type lines.
>>>>
>>>> Any chance you could tar.xz up the whole vmlinux build tree?
>>>
>>> Of course: https://www.dropbox.com/s/l7cvs773mw8jqga/build.tar.xz?dl=0 (193M)
>>
>> Any ideas?
>
> I haven't had a chance to look at your tree, but since stap can find
> register_shrinker() itself:
>
>> $ stap -L 'kernel.function("register_shrinker").*'
>> kernel.function("register_shrinker").call
>> kernel.function("register_shrinker").exported
>> kernel.function("register_shrinker").return
>
> But not any lines from it:
>
>> $ stap -v -L 'kernel.statement("register_shrinker@*:*")'
>> Pass 1: parsed user script and 116 library scripts using
>> 93372virt/31140res/3000shr/28456data kb, in 190usr/20sys/206real ms.
>> Pass 2: analyzed script: 0 probes, 0 functions, 0 embeds, 0 globals
>> using 131260virt/69116res/3764shr/66344data kb, in
> 310usr/40sys/354real ms.
>
> I'd say that the compiler has optimized and reorganized things to the
> point where systemtap can't recognize a single line number in that function.
Actually, register_shrinker was a random example: I was originally trying to
(and am still wanting to) set statement probes in an externally compiled
kernel module (zfsonlinux). That was (and is) failing the same way, so I
thought I'd try to go back to basics and ended up at register_shinker.
I haven't been able to set statement probes on anything I've tried: kernel,
modules, external modules.
For what it's worth, if this is expected to bring back all the line numbers
systemtap can find in the whole kernel, it's not finding any at all:
$ stap -v -L 'kernel.statement("*@*:*")'
Pass 1: parsed user script and 116 library scripts using 93372virt/31144res/3000shr/28456data kb, in 190usr/20sys/204real ms.
Pass 2: analyzed script: 0 probes, 0 functions, 0 embeds, 0 globals using 132988virt/70760res/3764shr/68072data kb, in 300usr/40sys/351real ms.
$
> So, what to do about it? Off the top of my head, you've got a few options:
>
> 1) One option would be to probe at a different spot, say either in the
> functions that call register_shrinker() or in the functions that
> register_shrinker() calls.
See above: I can't put statement probes in anywhere in any function.
> 2) Another option would be to try to lower the gcc's optimization level
> for that source file.
Surely shouldn't be required for the whole kernel? That would be a bloody
good optimiser! Or a really crap one. :-)
> 3) Since you are building your own kernel, you could add a tracepoint(s)
> to that function that contains the info you need at the point(s) you are
> interested in, then hook up systemtap to that tracepoint(s).
...or printks(). Yes, but that's what I'd like to avoid by using systemtap
statement probes.
Chris