Bug 4843 - systemtap doesn't support probing assembler functions anymore
Summary: systemtap doesn't support probing assembler functions anymore
Status: RESOLVED DUPLICATE of bug 4311
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-25 20:28 UTC by Andi Kleen
Modified: 2008-03-20 20:27 UTC (History)
0 users

See Also:
Host: x86_64-linux
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andi Kleen 2007-07-25 20:28:05 UTC
I have an old stp script that worked with some older systemtap version, but now
fails with a current one (CVS of 070718). After some investigation
it looks like stap cannot hook any pure assembler functions anymore.

e.g. on x86-64

# cat getuser.stp 
probe kernel.function("__get_user_4") {
}
# stap getuser.stp 
semantic error: no match for probe point while resolving probe point
kernel.function("__get_user_4")
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.

The function is there of course

# grep get_user_4 /proc/kallsyms
ffffffff80341f90 T __get_user_4

I would like to do this again. Can the regression be fixed please?
Comment 1 Frank Ch. Eigler 2007-07-28 21:46:07 UTC
In my F7 x86-64 ernel, I notice the same thing.  The reason may be that there
appears to be no dwarf data whatsoever for the function.  Did the default kernel
AFLAGS change recently?

IIRC, Roland's build-id patches include a piece that adds '-gdwarf' to all GAS
command lines.  That should cure this problem. http://lkml.org/lkml/2007/7/11/445

Another possible solution is to search the ELF symbol tables for probing targets.
This has come up before, in the context of debuginfo-less but otherwise normal
programs, but we haven't built this yet.  Perhaps we should transform this bug
report into that feature.
Comment 2 Andi Kleen 2007-07-30 09:03:53 UTC
Hmm, I didn't think mainline x86 kernels ever passed that option to the assembler.
Some older kernels did generate dwarf2 unwind tables for assembler code 
by default. Would that have been enough?

But I'm pretty sure it worked at some point because I had the old script around.
Comment 3 Frank Ch. Eigler 2007-07-30 19:39:11 UTC
> Some older kernels did generate dwarf2 unwind tables for assembler code 
> by default. Would that have been enough?

Quite possibly.

> But I'm pretty sure it worked at some point because I had the old script around.

Does an old systemtap work against a current kernel?
Comment 4 Roland McGrath 2007-09-07 21:42:35 UTC
Pure assembler functions never had DWARF info, and never will.
Even the assembler -g support does not generate function info, only source line
info.  If this ever worked before, it was doing ELF symbol lookup.
Comment 5 Bruno Abinader 2008-03-03 18:15:52 UTC
This bug affects systemtap.stress/current.stp test evaluation on arm architecture.
Output is below:

FAIL: systemtap.stress/current.stp compilation
Comment 6 Frank Ch. Eigler 2008-03-20 20:27:22 UTC
With support for symbol-table-based probing now getting under way, let's track
this there.

*** This bug has been marked as a duplicate of 4311 ***