[Bug translator/3534] New: support wildcarded linenumber probe syntax

[Bug translator/3534] New: support wildcarded linenumber probe syntax

[fche at redhat dot com]

Idea: probe kernel.function("function@*:*") would put a probe at
every ~instruction (line record) boundary within the function.
This would allow a script to collect detailed profile/coverage
information (albeit at a considerable trapping overhead cost).

-- 
           Summary: support wildcarded linenumber probe syntax
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=3534

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/3534] support wildcarded linenumber probe syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-11-17 01:45 -------
make that "kernel.statement", not "kernel.function".


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3534

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug translator/3534] New: support wildcarded linenumber probe syntax

[Vara Prasad]

fche at redhat dot com wrote:

>Idea: probe kernel.function("function@*:*") would put a probe at
>every ~instruction (line record) boundary within the function.
>This would allow a script to collect detailed profile/coverage
>information (albeit at a considerable trapping overhead cost).
>
>  
>
I am not sure i followed your idea. For example if I have the following 
function
If i specify probe 
kernel.statement("get_symbol_offset@kernel.kallsyms.c:*"), the above 
feature will place probes for every instruction of an executable 
statement in this case line nos 139, 145,146 and 148. Did i get your 
proposal correct?

If i got your above idea correct, is this proposal is to support tracing 
of a function without tracing other functions it calls.  In other words 
i am trying to understand what is the underlying motivation for this 
proposal.

132 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l132> 
static unsigned int get_symbol_offset(unsigned long pos)
133 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l133> 
{
134 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l134> 
u8 *name;
135 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l135> 
int i;
136 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l136> 

137 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l137> 
/* use the closest marker we have. We have markers every 256 positions,
138 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l138> 
* so that should be close enough */
139 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l139> 
name = &kallsyms_names[ kallsyms_markers[pos>>8] ];
140 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l140> 

141 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l141> 
/* sequentially scan all the symbols up to the point we're searching for.
142 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l142> 
* Every symbol is stored in a [<len>][<len> bytes of data] format, so we
143 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l143> 
* just need to add the len to the current pointer for every symbol we
144 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l144> 
* wish to skip */
145 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l145> 
for(i = 0; i < (pos&0xFF); i++)
146 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l146> 
name = name + (*name) + 1;
147 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l147> 

148 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l148> 
return name - kallsyms_names;
149 
<http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=eeac3e313b2bfa41f26a4ccd9235232593fb947c;hb=1b9bb3c14c60324b54645ffefbe6d270f9fd191c;f=kernel/kallsyms.c#l149> 
}

bye,
Vara Prasad

[Bug translator/3534] support wildcarded linenumber probe syntax

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2006-11-17 18:22 -------
To make tracing easier this needs a lineno() context function, probably just
parsing the pp like probefunc() does.  Perhaps sourcefile() as well...

In one-liner loops, would this fire just once, or for all iterations?
e.g., while (p->next) p = p->next;

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3534

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/3534] support wildcarded linenumber probe syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-11-17 18:25 -------
(In reply to comment #2)
> To make tracing easier this needs a lineno() context function, probably just
> parsing the pp like probefunc() does.  Perhaps sourcefile() as well...

Indeed.

> In one-liner loops, would this fire just once, or for all iterations?
> e.g., while (p->next) p = p->next;

We could define it either way.  Or: ".statement()" could refer to the *first*
dwarf debug line-record - i.e. the first executable chunk on that given
line.  A new ".statements()" could expand to *all* of them.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3534

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug translator/3534] support wildcarded linenumber probe syntax

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-01-21 14:45 -------
We should implement the syntax alternatives such as those
listed in bug #4904 comment #5.


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

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://sourceware.org/bugzilla/show_bug.cgi?id=3534

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.