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]

stap += dwarfless probing (phase 1)


Over the past month I've been working on SystemTap support for probing
without the benefit of dwarf information.  The first phase -- tracing
function entries and returns using elf information or a symbol-table
text file -- seems to be working.  Today I made my private "dwarfless"
git branch public.  Please feel free to try it out.

(BTW, I made pretty good progress on phase 2 -- access to function
args by arg number and to CPU registers by name -- this weekend,
and I hope to commit working tapsets with this support for i686 and
x86_64 in the next couple of days.  This should make the phase-1 work
more useful.  But I digress.)

The phase-1 feature adds the following options to the stap command:

--kelf -- Consult the elf info in vmlinux or module.ko if there's
no dwarf info (or the dwarf doesn't describe the assembly-language
function you want to probe).

--kmap[=FILE] -- Consult the symbol table contained in the specified
text file, which should be something like System.map or /proc/kallsyms.

--ignore-vmlinux -- For testing, pretend vmlinux can't be found.

--ignore-dwarf -- For testing, pretend that neither vmlinux nor
the module.ko files contain dwarf.

These features are described in the stap.1.in man page.  This man
page also contains a new section, "MAKING DO WITH SYMBOL TABLES,"
that describes the limitations of dwarfless probing.

In the test suite, the semok/nodwf*.stp tests show some things
you can do with dwarfless probing -- these scripts should run for
you if you remove the -p2 option -- and semko/nodwf*.stp show some
things you can't do.

Limitations/Caveats

As far as I know, my changes aren't architecture-dependent.  I've
tested this work on i386 and x86_64.  IBM will test it on powerpc
and s390.

Probing dwarfless modules works with elfutils 0.131 (thanks to a
change to dwfl_module_relocations()) but not 0.129.

Not every T or t symbol in the symbol table is a function.  Stap
can't tell the difference without dwarf info.  In particular,
setting return probes on symbols that aren't function entries can
mess up your system.  Considerable work is needed to make the
blacklist address all these new opportunities to hang oneself.
Stap currently rejects function("*") probes on modules that lack
dwarf, but other potentially dangerous wildcarding is accepted.

Dwarfless probing of user apps is not currently supported.  That's
phase 3.

The elf symbol table for a module contains file-name symbols.
Perhaps we can exploit these to permit limited probing based on
file name.  Unfortunately, these symbols aren't entirely accurate.
E.g., in uprobes.ko, all the extern functions appear to be in in the
build-generated uprobes.mod.c.

What I know about elfutils is based on tapsets.cxx, cscope, and
trial and error.  If my code does something that elfutils could
do for me, it's because I'm not aware of that feature.  Feel free
to educate me.

Comments and corrections are welcome.
Jim Keniston


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