This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can't set statement probe in self-built linux-4.4


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]