[Bug tapsets/11955] New: signal tapsets don't match

[Bug tapsets/11955] New: signal tapsets don't match

[andi-bz at firstfloor dot org]

Several of the probes in the signal tapset don't resolve to the kernel source.
Confirmed with 2.6.35 and 2.6.32

e.g.

probe signal.send { 
        if (sig == 7)
                printf("sending SIGBUS to %s\n", pid_name) 
}
probe signal.handle { 
        if (sig == 7) 
                printf("SIGBUS  %s, code %x handler %x\n", execname(),  
                        sig_code, @cast(ka_addr, "struct sigaction")->sa_handler)
} 

gives

semantic error: failed to retrieve location attribute for local 'info'
(dieoffset: 0x7bec1): identifier '$info' at
/pkg/systemtap-1.3/share/systemtap/tapset/signal.stp:610:16
        source:     sig_code = $info->si_code
                               ^
semantic error: failed to retrieve location attribute for local 'ka' (dieoffset:
0x7bebc): identifier '$ka' at :611:15
        source:     ka_addr = $ka
                              ^
Pass 2: analysis failed.  Try again with another '--vp 01' option.

-- 
           Summary: signal tapsets don't match
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: andi-bz at firstfloor dot org


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

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

[Bug tapsets/11955] signal tapsets don't match

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2010-08-29 12:51 -------
They happen to resolve on my fedora kernel build:

$ stap test.stp 
sending SIGBUS to bash
SIGBUS  bash, code 0 handler 8096700
sending SIGBUS to bash

Linux version 2.6.33.8-149.fc13.i686 (mockbuild@x86-09.phx2.fedoraproject.org)
(gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Tue Aug 17
22:45:56 UTC 2010

A "semantic error: failed to retrieve location attribute for local" is often a
compiler bug. As you can see in your error message there is a DIE for the local
variable, but it is missing the location attribute that describes where (in
memory or through registers) this variable can be found. (Note that the fedora
gcc has the VTA patches from gcc 4.5 backported, which help a lot in describing
location information for inlined code/variables.)

Which compiler was used to build your kernel?

You can get a bit more info about what is known about the local variables by
looking up the dieoffset given in the error message with something like
[eu-]readelf [-N] --debug-dump=info /path/to/vmlinux.debuginfo | less

-- 


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

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

[Bug tapsets/11955] signal tapsets don't match

[andi-bz at firstfloor dot org]

------- Additional Comments From andi-bz at firstfloor dot org  2010-08-29 19:45 -------
The 2.6.35 kernel was built with gcc 4.5
The 2.6.32 with an earlier release I believe.


-- 


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

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

[Bug tapsets/11955] signal tapsets don't match

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-09-01 16:27 -------
While this appears to be a pretty typical poor-debuginfo gcc problem,
we may be able to work around it by changing the probe points slightly.
signal.send appears to be OK, but signal.handle may be inlined.  So we
could perhaps probe kernel.function("get_signal_to_deliver").return,
skipping if the signr == 0.


-- 


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

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