headers
fche at redhat dot com | 1 Dec 2007 01:00
Favicon

[Bug documentation/5438] Add libcap-devel to README


------- Additional Comments From fche at redhat dot com  2007-12-01 00:00 -------
patch applied, thanks!

--

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

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

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Julio M. Merino Vidal | 1 Dec 2007 11:07
Favicon

Using markers

Hello,

I am interested in getting traces of the SPU scheduler in the Cell  
platform.  SystemTap seems like an excellent candidate to take those  
traces but I'm having some trouble getting it to work as I need.   
Using probes at function entry/exit points works in most cases, which  
is great, but some of the functions I'm interested in tracing are  
declared as static and therefore the debugging information lacks some  
details to access such as, for example, their parameters.

So I've considered using markers as the documentation explains, but I  
cannot get them to work.  Based on bug 4446, I understand that the  
CONFIG_MARKERS support that is in Linux 2.6.23 is not yet supported  
by SystemTap (even though I did try them), so I tried to use the  
macros defined in stapmark.h as shipped by SystemTap's Git  
repository.  But those don't seem to work either.

Here is what I added in the probe's point:

trace_mark(spufs_bind_context_new, "spu %d ctx %p", spu->number, ctx);
STAP_MARK_NN(spufs_bind_context_old, (int64_t)spu->number, (int64_t) 
ctx);

And here is my test stp file:

probe test.new = kernel.mark("spufs_bind_context_new") { name = "new" }
probe test.old = kernel.mark("spufs_bind_context_old") { name = "old" }
probe test.* { log("marker ".name." hit") }

But then, when running stap on this script, none of the two markers
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marcin Krol | 1 Dec 2007 11:34
Picon
Favicon

Lack of system_utsname in recent kernels may prevent some systemtap programs from compiling

Hello everyone,

I think systemtap developers should be notified about this.

I found this note in
http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.19-rc1

commit bf47fdcda65b44dbd674eeedcaa06e0aa28a5a00
Author: Serge E. Hallyn <serue <at> us.ibm.com>
Date:   Mon Oct 2 02:18:16 2006 -0700

    [PATCH] namespaces: utsname: remove system_utsname

    The system_utsname isn't needed now that kernel/sysctl.c is fixed.
    Nuke it.

    Signed-off-by: Serge E. Hallyn <serue <at> us.ibm.com>
    Cc: Kirill Korotaev <dev <at> openvz.org>
    Cc: "Eric W. Biederman" <ebiederm <at> xmission.com>
    Cc: Herbert Poetzl <herbert <at> 13thfloor.at>
    Cc: Andrey Savochkin <saw <at> sw.ru>
    Signed-off-by: Andrew Morton <akpm <at> osdl.org>
    Signed-off-by: Linus Torvalds <torvalds <at> osdl.org>

So it seems system_utsname has been deleted, while when I try to compile
this program (using recent stap compiled from CVS):

% cat embed-C.stp
%{
#include <linux/utsname.h>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Marcin Krol | 1 Dec 2007 11:53
Picon
Favicon

Re: Lack of system_utsname in recent kernels may prevent some systemtap programs from compiling

Hello everyone,

I just realized I should rather correct this example from tutorial, 
since linux/utsname.h has changed.

However, I still don't get why I can't compile this updated example, 
since /usr/include/linux/utsname.h does include relevant structures:

struct new_utsname {
        char sysname[65];
        char nodename[65];
        char release[65];
        char version[65];
        char machine[65];
        char domainname[65];
};

% cat embed-C.stp
%{
#include <linux/utsname.h>
%}
function utsname:string (field:long)
%{
  if (down_read_trylock (& uts_sem))
    {
      const char *f =
         (THIS->field == 0 ? new_utsname.sysname :
          THIS->field == 1 ? new_utsname.nodename :
          THIS->field == 2 ? new_utsname.release :
          THIS->field == 3 ? new_utsname.version :
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marcin Krol | 1 Dec 2007 12:05
Picon
Favicon

syscall.open

Hello everyone,

Anybody knows why this tutorial example can't run?

probe syscall.open
{
  printf ("%s(%d) open (%s)\n", execname(), pid(), argstr)
}
probe timer.ms(4000) # after 4 seconds
{
  exit ()
}

I took care to include following flags in kernel  .config:

CONFIG_KPROBES=y
CONFIG_DEBUG_INFO=y
CONFIG_RELAY=y
CONFIG_DEBUG_FS=y

CONFIG_DEBUG_KERNEL=y

I get this error:

% stap strace-open.stp
semantic error: libdwfl failure (missing kernel debuginfo): No such file 
or directory while resolving probe point kernel.function("sys_open")?
semantic error: no match while resolving probe point syscall.open

I have systemtap compiled from recent CVS, with stap elfutils compiled
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wenji Huang | 3 Dec 2007 03:04
Picon
Favicon

Re: Lack of system_utsname in recent kernels may prevent some systemtap programs from compiling

Marcin Krol wrote:

> Hello everyone,
>
> I just realized I should rather correct this example from tutorial, 
> since linux/utsname.h has changed.
>
> However, I still don't get why I can't compile this updated example, 
> since /usr/include/linux/utsname.h does include relevant structures:
>
> struct new_utsname {
>        char sysname[65];
>        char nodename[65];
>        char release[65];
>        char version[65];
>        char machine[65];
>        char domainname[65];
> };
>
>
> % cat embed-C.stp
> %{
> #include <linux/utsname.h>
> %}
> function utsname:string (field:long)
> %{
>  if (down_read_trylock (& uts_sem))
>    {
>      const char *f =
>         (THIS->field == 0 ? new_utsname.sysname :
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wenji Huang | 3 Dec 2007 03:14
Picon
Favicon

Re: syscall.open

Marcin Krol wrote:

> Hello everyone,
>
> Anybody knows why this tutorial example can't run?
>
> probe syscall.open
> {
>  printf ("%s(%d) open (%s)\n", execname(), pid(), argstr)
> }
> probe timer.ms(4000) # after 4 seconds
> {
>  exit ()
> }
>
>
> I took care to include following flags in kernel  .config:
>
> CONFIG_KPROBES=y
> CONFIG_DEBUG_INFO=y
> CONFIG_RELAY=y
> CONFIG_DEBUG_FS=y
>
> CONFIG_DEBUG_KERNEL=y
>
> I get this error:
>
> % stap strace-open.stp
> semantic error: libdwfl failure (missing kernel debuginfo): No such 
> file or directory while resolving probe
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Smith | 3 Dec 2007 17:28
Picon
Favicon

Re: Using markers

Julio M. Merino Vidal wrote:
> Hello,
> 
> I am interested in getting traces of the SPU scheduler in the Cell
> platform.  SystemTap seems like an excellent candidate to take those
> traces but I'm having some trouble getting it to work as I need.  Using
> probes at function entry/exit points works in most cases, which is
> great, but some of the functions I'm interested in tracing are declared
> as static and therefore the debugging information lacks some details to
> access such as, for example, their parameters.
> 
> So I've considered using markers as the documentation explains, but I
> cannot get them to work.  Based on bug 4446, I understand that the
> CONFIG_MARKERS support that is in Linux 2.6.23 is not yet supported by
> SystemTap (even though I did try them), so I tried to use the macros
> defined in stapmark.h as shipped by SystemTap's Git repository.  But
> those don't seem to work either.

We should probably remove stapmark.h since we don't support it.

> Here is what I added in the probe's point:
> 
> trace_mark(spufs_bind_context_new, "spu %d ctx %p", spu->number, ctx);
> STAP_MARK_NN(spufs_bind_context_old, (int64_t)spu->number, (int64_t)ctx);
> 
> And here is my test stp file:
> 
> probe test.new = kernel.mark("spufs_bind_context_new") { name = "new" }
> probe test.old = kernel.mark("spufs_bind_context_old") { name = "old" }
> probe test.* { log("marker ".name." hit") }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Nomura | 3 Dec 2007 19:08
Picon
Favicon

Re: user instruction tracing patch?

So what do you think the next steps are to move forward on this issue?  

Did you have some expectations on who would do this translator work?

 From your discussion it sounded like some of these issues were more 
general than just instruction tracing.
Are there plans to do any of that work?

Frank Ch. Eigler wrote:
> Hi -
>
>   
>> Did you have any comments on the actual content of my patch?
>>     
>
> Yes, it was a good proof-of-concept of using utrace as the
> instruction-stepping infrastructure.
>
>   
>> Did you want to resolve the translator syntax changes to support
>> instruction tracing first?
>>     
>
> I believe we do need proper translator-side support for this feature,
> beyond what the tapset-only prototype provides.  We need end-user
> scripts using itrace should not to have to use embedded-c code, and
> we need the implementation to be robust (i.e., not require users
> to match each "turn on itrace for pid PID" with "... off ...".
>
> The first pair of probe point extensions listed in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julio M. Merino Vidal | 3 Dec 2007 20:58
Favicon

Re: Using markers

On 03/12/2007, at 17:28, David Smith wrote:

> Julio M. Merino Vidal wrote:
>> Hello,
>>
>> I am interested in getting traces of the SPU scheduler in the Cell
>> platform.  SystemTap seems like an excellent candidate to take those
>> traces but I'm having some trouble getting it to work as I need.   
>> Using
>> probes at function entry/exit points works in most cases, which is
>> great, but some of the functions I'm interested in tracing are  
>> declared
>> as static and therefore the debugging information lacks some  
>> details to
>> access such as, for example, their parameters.
>>
>> So I've considered using markers as the documentation explains, but I
>> cannot get them to work.  Based on bug 4446, I understand that the
>> CONFIG_MARKERS support that is in Linux 2.6.23 is not yet  
>> supported by
>> SystemTap (even though I did try them), so I tried to use the macros
>> defined in stapmark.h as shipped by SystemTap's Git repository.  But
>> those don't seem to work either.
>
> We should probably remove stapmark.h since we don't support it.

fche already did it.

>> Here is what I added in the probe's point:
>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane