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

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

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #4 from David Smith <dsmith at redhat dot com> 2013-01-31 16:42:18 UTC ---
This problem has gotten a bit worse. Besides the fact that handle_signal() is
typically inlined (and we usually can't find the parameters), in current
kernels the list of parameters has changed and there is no longer a set/oldset
argument. We didn't notice the missing argument since signal.handle hasn't
worked for awhile.

The suggestion in comment #3 of probing
kernel.function("get_signal_to_deliver").return
(and skipping if the signr == 0) might work for the 'signal.handle' probe
alias, but I'm unsure what we'd do about the 'signal.handle.return' probe
alias. Just deprecate it?

In current kernels, a good function to probe might be the generic
'signal_delivered' kernel function, which is called from the arch-specific
handle_signal().

Another option here might be to use the 'signal_delivered' tracepoint, although
the list of parameters is a subset of 'handle_signal'. Note that I haven't
tracked down exactly where that one gets called from in the kernel, so I'm not
sure how close of a match it is.

Finding a good solution here that handles a large range of kernels will be
tricky.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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

[dsmith at redhat dot com]

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

David Smith <dsmith at redhat dot com> changed:

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

--- Comment #5 from David Smith <dsmith at redhat dot com> 2013-02-01 17:04:39 UTC ---
Fixed in commit 9907664. The 'signal.send' and 'signal.handle' tapset aliases
have been switch to use tracepoints.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[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.

[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

[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.