* Linux kernel marker questions
@ 2007-05-22 16:38 David Smith
2007-05-23 7:10 ` Mathieu Desnoyers
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: David Smith @ 2007-05-22 16:38 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: Systemtap List, ltt-dev
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.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-22 16:38 Linux kernel marker questions David Smith
@ 2007-05-23 7:10 ` Mathieu Desnoyers
2007-05-23 21:15 ` Mike Mason
2007-05-28 18:23 ` Mathieu Desnoyers
2 siblings, 0 replies; 16+ messages in thread
From: Mathieu Desnoyers @ 2007-05-23 7:10 UTC (permalink / raw)
To: David Smith; +Cc: Systemtap List, ltt-dev
Hi David,
I am currently on vacation, so I'll reply in full on May 28, when I'll
be back. Meanwhile, you can get a head-start by looking at the new
implementation of the markers in LTTng 0.9.6 (http://ltt.polymtl.ca): I
modified it quite a bit, taking in consideration comments from the
kernel community. The API did not change much though (just be cautious
of the new return value of marker_arm_probe, which is the logical
opposite of the old marker_set_probe).
Regards,
Mathieu
* David Smith (dsmith@redhat.com) 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.
>
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-22 16:38 Linux kernel marker questions David Smith
2007-05-23 7:10 ` Mathieu Desnoyers
@ 2007-05-23 21:15 ` Mike Mason
2007-05-24 13:21 ` David Smith
2007-05-28 18:23 ` Mathieu Desnoyers
2 siblings, 1 reply; 16+ messages in thread
From: Mike Mason @ 2007-05-23 21:15 UTC (permalink / raw)
To: David Smith; +Cc: Mathieu Desnoyers, Systemtap List
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.
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-23 21:15 ` Mike Mason
@ 2007-05-24 13:21 ` David Smith
2007-05-24 13:59 ` Mike Mason
0 siblings, 1 reply; 16+ messages in thread
From: David Smith @ 2007-05-24 13:21 UTC (permalink / raw)
To: Mike Mason; +Cc: Mathieu Desnoyers, Systemtap List
Mike Mason wrote:
> 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?
Yes it should work - depending on which version of Mathieu's patches
you've got. I've bet we've got differing versions if you are getting
the "bad __markers_string section" message. I've been using the version
of Mathieu's patches that Andrew Morton has. I can send you a copy of
the patches I've been using if you'd like.
One more thing - your marker is called "sem_down", but you look to be
putting a probe on "sem_up"...
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-24 13:21 ` David Smith
@ 2007-05-24 13:59 ` Mike Mason
2007-05-24 14:13 ` David Smith
0 siblings, 1 reply; 16+ messages in thread
From: Mike Mason @ 2007-05-24 13:59 UTC (permalink / raw)
To: David Smith; +Cc: Mathieu Desnoyers, Systemtap List
David Smith wrote:
> Mike Mason wrote:
>> 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?
>
> Yes it should work - depending on which version of Mathieu's patches
> you've got. I've bet we've got differing versions if you are getting
> the "bad __markers_string section" message. I've been using the version
> of Mathieu's patches that Andrew Morton has. I can send you a copy of
> the patches I've been using if you'd like.
I'm using a version of the Andrew's patches, but perhaps not the latest. Please send me what you're using.
>
> One more thing - your marker is called "sem_down", but you look to be
> putting a probe on "sem_up"...
>
Oops, cut-and-paste error. I do have a "sem_up" marker as well.
BTW, what data can be accessed in a SystemTap marker probe handler? Can it access the data defined by the marker or any local or global variables?
Thanks,
Mike
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-24 13:59 ` Mike Mason
@ 2007-05-24 14:13 ` David Smith
0 siblings, 0 replies; 16+ messages in thread
From: David Smith @ 2007-05-24 14:13 UTC (permalink / raw)
To: Mike Mason; +Cc: Mathieu Desnoyers, Systemtap List
Mike Mason wrote:
> David Smith wrote:
>> Mike Mason wrote:
>>> Should this work yet?
>>
>> Yes it should work - depending on which version of Mathieu's patches
>> you've got. I've bet we've got differing versions if you are getting
>> the "bad __markers_string section" message. I've been using the
>> version of Mathieu's patches that Andrew Morton has. I can send you a
>> copy of the patches I've been using if you'd like.
>
> I'm using a version of the Andrew's patches, but perhaps not the
> latest. Please send me what you're using.
I'll send you the patches I've been using.
> BTW, what data can be accessed in a SystemTap marker probe handler? Can
> it access the data defined by the marker or any local or global variables?
You'll only be able to access the data defined by the marker using
"$argN" (where "N" is 1 through the number of arguments).
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-22 16:38 Linux kernel marker questions David Smith
2007-05-23 7:10 ` Mathieu Desnoyers
2007-05-23 21:15 ` Mike Mason
@ 2007-05-28 18:23 ` Mathieu Desnoyers
2007-05-29 13:24 ` David Smith
2007-05-29 21:00 ` Linux kernel marker questions Frank Eigler
2 siblings, 2 replies; 16+ messages in thread
From: Mathieu Desnoyers @ 2007-05-28 18:23 UTC (permalink / raw)
To: David Smith; +Cc: Systemtap List, ltt-dev
* David Smith (dsmith@redhat.com) 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?
>
Yes. A marker can be declared more than once, but bears the same
semantics and should have the same parameter types.
> _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.
>
See answer below. Also, if a marker is defined in an inline function or
an unrolled loop (this last optimization is disabled in the kernel build
though), it will result in multiple occurences of the marker.
> 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?
>
Correct. It could be fixed by adapting _marker_set_probe, making it take
an optinional struct module* argument. It will have more effects on the
forthcoming markers version though, since I keep a data structure of the
active markers throrough the kernel, so that if a marker is set before a
module is loaded, the marker will be activated at module load time.
> 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.
>
format string and flags are only there to make sure nobody writes
foolishly a "bad" probe without considering the reentrancy impact and
by expecting the wrong arguments. Note that passing a NULL format string
is valid and means that the probe will parse the string dynamicall,
therefore getting around the verification.
> 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?
>
Hrm.. well, isn't this information is a __markers section, which points
to a __markers data section ? It seems to me that it could be extracted
from the binary too, just like the __markers_strings. Please keep in
mind that these sections and data structures will change in the
forthcoming markers version.
> 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?
>
It will change in the new version. I guess we should rediscuss it once I
submit the new patches.
> Thanks for the help.
>
Thanks for your collaboration, I hope I answered to your questions
appropriately.
Mathieu
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-28 18:23 ` Mathieu Desnoyers
@ 2007-05-29 13:24 ` David Smith
2007-05-29 14:15 ` Target variable that was defined by our own kernel module John Liang
2007-05-29 21:00 ` Linux kernel marker questions Frank Eigler
1 sibling, 1 reply; 16+ messages in thread
From: David Smith @ 2007-05-29 13:24 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: Systemtap List, ltt-dev
Mathieu Desnoyers wrote:
> * David Smith (dsmith@redhat.com) wrote:
>> Am I correct that unique marker names are not strictly enforced but
>> "uniqueness" is more of a convention?
>
> Yes. A marker can be declared more than once, but bears the same
> semantics and should have the same parameter types.
OK.
>> 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?
>>
>
> Correct. It could be fixed by adapting _marker_set_probe, making it take
> an optinional struct module* argument.
That might be useful. I can see situations where you would want to
enable a marker only in a specific module.
>> 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.
>>
>
> format string and flags are only there to make sure nobody writes
> foolishly a "bad" probe without considering the reentrancy impact and
> by expecting the wrong arguments. Note that passing a NULL format string
> is valid and means that the probe will parse the string dynamicall,
> therefore getting around the verification.
OK, so I can pass a NULL as the format string. I'm more worried at this
point about the flags than the format string, since I currently don't
have a way to retrieve the flags.
>> 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?
>>
>
> Hrm.. well, isn't this information is a __markers section, which points
> to a __markers data section ? It seems to me that it could be extracted
> from the binary too, just like the __markers_strings. Please keep in
> mind that these sections and data structures will change in the
> forthcoming markers version.
In the kernel that I built using your patches, I end up with a
'__markers' section (which basically contains the enabled state of each
marker), and the '__markers_strings' section, which contains the marker
names and format strings. The '__markers_data' section doesn't exist as
a separate section, it is just part of the data section.
Of course another problem I've got is that the definitions of the data
structures aren't available from user-space.
>> 3) From systemtap's point of view, _marker_set_probe() doesn't return
>> enough error information.
>>
>> Would there be any way of getting more detailed error information?
>>
>
> It will change in the new version. I guess we should rediscuss it once I
> submit the new patches.
Great. Do you have any ideas on when you plan on submitting the new
patches?
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Target variable that was defined by our own kernel module
2007-05-29 13:24 ` David Smith
@ 2007-05-29 14:15 ` John Liang
2007-05-29 15:09 ` David Smith
0 siblings, 1 reply; 16+ messages in thread
From: John Liang @ 2007-05-29 14:15 UTC (permalink / raw)
To: 'Systemtap List'
HI There,
For the following systemtap script, I run into a compiler error:
probe module("mymodule").("foobar"){
if($myparm)
dosomething
}
It looks if $myparm is a data structure defined in Linux Kernel,
It would compile and run without problem; but if it is a defined
by my own module, then it gave me a "unresolved symbol error for
$myparm".
Any suggestions to solve this?
Thanks,
--
John Liang
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Target variable that was defined by our own kernel module
2007-05-29 14:15 ` Target variable that was defined by our own kernel module John Liang
@ 2007-05-29 15:09 ` David Smith
2007-05-29 17:27 ` John Liang
2007-05-29 18:03 ` Stone, Joshua I
0 siblings, 2 replies; 16+ messages in thread
From: David Smith @ 2007-05-29 15:09 UTC (permalink / raw)
To: John Liang; +Cc: 'Systemtap List'
John Liang wrote:
> HI There,
>
> For the following systemtap script, I run into a compiler error:
>
> probe module("mymodule").("foobar"){
> if($myparm)
> dosomething
> }
That first line should be:
probe module("mymodule").function("foobar"){
> It looks if $myparm is a data structure defined in Linux Kernel,
> It would compile and run without problem; but if it is a defined
> by my own module, then it gave me a "unresolved symbol error for
> $myparm".
>
> Any suggestions to solve this?
Make sure the debug information is installed for your kernel module.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Target variable that was defined by our own kernel module
2007-05-29 15:09 ` David Smith
@ 2007-05-29 17:27 ` John Liang
2007-05-29 18:19 ` David Smith
2007-05-29 18:03 ` Stone, Joshua I
1 sibling, 1 reply; 16+ messages in thread
From: John Liang @ 2007-05-29 17:27 UTC (permalink / raw)
To: 'David Smith'; +Cc: 'Systemtap List'
David,
Do you mean I need to create a mymodule-debuginfo rpm in the
same way as for kernel-debuginfo of Linux?
Thanks,
--
John Liang
-----Original Message-----
From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
On Behalf Of David Smith
Sent: Tuesday, May 29, 2007 11:09 AM
To: John Liang
Cc: 'Systemtap List'
Subject: Re: Target variable that was defined by our own kernel module
John Liang wrote:
> HI There,
>
> For the following systemtap script, I run into a compiler error:
>
> probe module("mymodule").("foobar"){
> if($myparm)
> dosomething
> }
That first line should be:
probe module("mymodule").function("foobar"){
> It looks if $myparm is a data structure defined in Linux Kernel,
> It would compile and run without problem; but if it is a defined
> by my own module, then it gave me a "unresolved symbol error for
> $myparm".
>
> Any suggestions to solve this?
Make sure the debug information is installed for your kernel module.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Target variable that was defined by our own kernel module
2007-05-29 15:09 ` David Smith
2007-05-29 17:27 ` John Liang
@ 2007-05-29 18:03 ` Stone, Joshua I
1 sibling, 0 replies; 16+ messages in thread
From: Stone, Joshua I @ 2007-05-29 18:03 UTC (permalink / raw)
To: David Smith; +Cc: John Liang, 'Systemtap List'
David Smith wrote:
> John Liang wrote:
> [...]
>> It looks if $myparm is a data structure defined in Linux Kernel,
>> It would compile and run without problem; but if it is a defined
>> by my own module, then it gave me a "unresolved symbol error for
>> $myparm".
>> Any suggestions to solve this?
>
> Make sure the debug information is installed for your kernel module.
If it were a problem of locating the debuginfo, I expect that it
wouldn't even resolve the function, right?
It still may be a case of inadequate debugging information though.
Perhaps that variable got optimized away, or it may be one of our
beloved problems with gcc.
Josh
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Target variable that was defined by our own kernel module
2007-05-29 17:27 ` John Liang
@ 2007-05-29 18:19 ` David Smith
0 siblings, 0 replies; 16+ messages in thread
From: David Smith @ 2007-05-29 18:19 UTC (permalink / raw)
To: John Liang; +Cc: 'Systemtap List'
John Liang wrote:
> David,
>
> Do you mean I need to create a mymodule-debuginfo rpm in the
> same way as for kernel-debuginfo of Linux?
Yes or no - depending on how you compile your module.
If you are building via rpmbuild, it should automatically create a
debuginfo rpm for you which you would then install.
If you are building by hand or via a Makefile, you'll need to ensure the
module isn't stripped (I believe).
Also, a more exact error message could help us out here.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Linux kernel marker questions
2007-05-28 18:23 ` Mathieu Desnoyers
2007-05-29 13:24 ` David Smith
@ 2007-05-29 21:00 ` Frank Eigler
2007-05-30 15:28 ` [Ltt-dev] " Mathieu Desnoyers
1 sibling, 1 reply; 16+ messages in thread
From: Frank Eigler @ 2007-05-29 21:00 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: David Smith, Systemtap List, ltt-dev
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:
> [...] Yes. A marker can be declared more than once, but bears the
> same semantics and should have the same parameter types.
Will the registration API do the right thing with enforcing this?
> [...] Correct. It could be fixed by adapting _marker_set_probe,
> making it take an optinional struct module* argument. [...]
Unfortunately, it is hard to get a struct module* by a module. When
last year, we tried to submit a plain module_get_byname() api call, it
got blocked. Should we try again (with the same patch, natch)?
> forthcoming markers version though, since I keep a data structure of the
> active markers throrough the kernel, so that if a marker is set before a
> module is loaded, the marker will be activated at module load time.
OK, but we will probably still need a separate namespace.
> > 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.
>
> format string and flags are only there to make sure nobody writes
> foolishly a "bad" probe [...]
For a client such as systemtap, marker probes will be atomic.
> [...] Please keep in mind that these sections and data structures
> will change in the forthcoming markers version. [...]
I hope it settles down soon. If it doesn't, it will become necessary
to add versioning tags to the marker data so we can guide our decoder.
- FChE
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Ltt-dev] Linux kernel marker questions
2007-05-29 21:00 ` Linux kernel marker questions Frank Eigler
@ 2007-05-30 15:28 ` Mathieu Desnoyers
2007-05-30 17:01 ` Frank Ch. Eigler
0 siblings, 1 reply; 16+ messages in thread
From: Mathieu Desnoyers @ 2007-05-30 15:28 UTC (permalink / raw)
To: Frank Eigler; +Cc: David Smith, ltt-dev, Systemtap List
* Frank Eigler (fche@redhat.com) wrote:
> Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:
>
> > [...] Yes. A marker can be declared more than once, but bears the
> > same semantics and should have the same parameter types.
>
> Will the registration API do the right thing with enforcing this?
>
If the format passed to marker_arm_probe is not NULL, each marker will
be checked to match the same format. If not, connexion fails.
>
> > [...] Correct. It could be fixed by adapting _marker_set_probe,
> > making it take an optinional struct module* argument. [...]
>
> Unfortunately, it is hard to get a struct module* by a module. When
> last year, we tried to submit a plain module_get_byname() api call, it
> got blocked. Should we try again (with the same patch, natch)?
>
You could pass a module name to the marker_arm_probe then, instead of a
struct module*. Since marker_arm_probe sits in module.c, it makes things
easy. :)
> > forthcoming markers version though, since I keep a data structure of the
> > active markers throrough the kernel, so that if a marker is set before a
> > module is loaded, the marker will be activated at module load time.
>
> OK, but we will probably still need a separate namespace.
>
Hrm, what if you use a semantic like "module_name__subsys_event" in the
marker names ? You could then control marker activation per module if
you like without adding any complexity to the marker infrastructure.
> > > 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.
> >
> > format string and flags are only there to make sure nobody writes
> > foolishly a "bad" probe [...]
>
> For a client such as systemtap, marker probes will be atomic.
>
ok, so if you do not call things like local_irq_enable, nor fall into
debug traps in the handler, you can use the CF_DEFAULT flag for the
marker_arm_probe when you arm your probe : it will imply that your probe
handler won't call into lockdep nor call printk. (meaning that you have
to do everything atomically and, if you _really_ need to do such things
like disabling interrupts, you must use the raw versions which does not
call lockdep).
> > [...] Please keep in mind that these sections and data structures
> > will change in the forthcoming markers version. [...]
>
> I hope it settles down soon. If it doesn't, it will become necessary
> to add versioning tags to the marker data so we can guide our decoder.
>
My feeling it that it should probably go into mainline for 2.6.23, but
things should settle down sooner.
>
> - FChE
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Ltt-dev] Linux kernel marker questions
2007-05-30 15:28 ` [Ltt-dev] " Mathieu Desnoyers
@ 2007-05-30 17:01 ` Frank Ch. Eigler
0 siblings, 0 replies; 16+ messages in thread
From: Frank Ch. Eigler @ 2007-05-30 17:01 UTC (permalink / raw)
To: Mathieu Desnoyers; +Cc: ltt-dev, Systemtap List
Hi, Mathieu -
> You could pass a module name to the marker_arm_probe then, instead of a
> struct module*. Since marker_arm_probe sits in module.c, it makes things
> easy. :)
Indeed.
> > > forthcoming markers version though, since I keep a data structure of the
> > > active markers throrough the kernel, so that if a marker is set before a
> > > module is loaded, the marker will be activated at module load time.
> >
> > OK, but we will probably still need a separate namespace.
>
> Hrm, what if you use a semantic like "module_name__subsys_event" in the
> marker names ? You could then control marker activation per module if
> you like without adding any complexity to the marker infrastructure.
But the namespace reflects the actual complexity of the system. If
you defer marker insertion for modules being loaded on-the-fly, then
the code already knows modules are special, and most of the complexity
is already there.
> > For a client such as systemtap, marker probes will be atomic.
>
> ok, so if you do not call things like local_irq_enable, nor fall into
> debug traps in the handler, you can use the CF_DEFAULT flag [...]
OK.
> (meaning that you have to do everything atomically and, if you
> _really_ need to do such things like disabling interrupts, you must
> use the raw versions which does not call lockdep).
I don't entirely understand the issue with lockdep. Is the problem
only that it reports errors via printk? Could you send a pointer to
more detailed information on new atomicity constraints due to lockdep?
- FChE
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-05-30 17:01 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-22 16:38 Linux kernel marker questions David Smith
2007-05-23 7:10 ` Mathieu Desnoyers
2007-05-23 21:15 ` Mike Mason
2007-05-24 13:21 ` David Smith
2007-05-24 13:59 ` Mike Mason
2007-05-24 14:13 ` David Smith
2007-05-28 18:23 ` Mathieu Desnoyers
2007-05-29 13:24 ` David Smith
2007-05-29 14:15 ` Target variable that was defined by our own kernel module John Liang
2007-05-29 15:09 ` David Smith
2007-05-29 17:27 ` John Liang
2007-05-29 18:19 ` David Smith
2007-05-29 18:03 ` Stone, Joshua I
2007-05-29 21:00 ` Linux kernel marker questions Frank Eigler
2007-05-30 15:28 ` [Ltt-dev] " Mathieu Desnoyers
2007-05-30 17:01 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).