This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Linux kernel marker questions
- From: Mike Mason <mmlnx at us dot ibm dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, Systemtap List <systemtap at sources dot redhat dot com>
- Date: Wed, 23 May 2007 14:14:56 -0700
- Subject: Re: Linux kernel marker questions
- References: <46531C6E.3010502@redhat.com>
David,
Is there enough marker support in CVS now that we can write scripts against it? I tried using the latest CVS against a kernel with a few markers, but I'm seeing errors.
Here's the script:
global sem_up_cnt
probe kernel.mark("sem_up") { sem_up_cnt++ }
probe end { printf("sem_up_cnt = %d\n", sem_up_cnt)}
Here's the marker I'm trying to access in __up() in semaphore-sleepers.c:
MARK(sem_down, "%ul", (unsigned long) sem);
Here are the errors I'm seeing:
semantic error: bad __markers_string section?
semantic error: no match for probe point while resolving probe point kernel.mark("sem_up")
Should this work yet?
Thanks,
Mike
David Smith wrote:
Mathieu,
I've just finished checking in initial support for your new kernel
markers into systemtap. I've got some rough edges to work on, but in
general it works.
As I implemented the marker support, I come up with several questions
I'd like some help/clarification with.
1) According to Documentation/marker.txt, the marker name
(subsystem_event) is "is an identifier unique to your event".
Am I correct that unique marker names are not strictly enforced but
"uniqueness" is more of a convention?
_marker_set_probe() seems to support the view that marker names aren't
unique since it doesn't stop looking for more marker matches once it
finds a match.
One problem this creates for systemtap is that systemtap's probe syntax
looks like 'kernel.mark("marker_name")' and
'module("module_name").mark('marker_name'). I believe with the current
code if a marker exists with the same name, format string, and flags in
the kernel and a loadable module there isn't any way to only enable the
marker in one place or the other - you can only enable both markers
(assuming the module is loaded). Am I correct?
2) _marker_set_probe() expects the marker name, format string, and flags
that were specified when the marker was inserted. If marker names were
truly unique, I would really only need the marker name to enable a marker.
Since systemtap can compile modules for a kernel that isn't running, I
can't really use marker_list_probe() for getting a list of markers
present (even if the output of marker_list_probe() was more than just
printks). So, currently to get a list of markers for a particular
kernel, the code reads and parses the kernel/module '__markers_strings'
elf section, which gets systemtap the marker names and format strings.
(Getting the marker flags out of a kernel/module elf file is possible,
but won't be easy.)
Currently systemtap can only enable markers that used the MF_DEFAULT set
of flags.
Have you got any ideas on how systemtap (or any other program) can get a
list of all the data _marker_set_probe needs?
3) From systemtap's point of view, _marker_set_probe() doesn't return
enough error information. Currently it just returns the number of
probes enabled. If _marker_set_probe returns a 0 (meaning no markers
were enabled), I don't know which of the following that means:
- the marker name wasn't found
- the marker name was found, but format string didn't match the compiled
format string
- the marker name was found and the format strings matched, but the
marker flags didn't match the compiled marker flags
- the marker is already enabled (since markers can only have one
function attached to them at a time)
Would there be any way of getting more detailed error information?
Thanks for the help.