+++ This bug was initially created as a clone of Bug #613822 +++
Description of problem:
When attempting to use some of the variable avialable in the hotspot tapset found that some of the arguments were not available.
Version-Release number of selected component (if applicable):
systemtap-1.2-1.fc13.x86_64
java-1.6.0-openjdk-1.6.0.0-41.b18.fc13.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-41.b18.fc13.x86_64
java-1.6.0-openjdk-debuginfo-1.6.0.0-41.b18.fc13.x86_64
How reproducible:
everytime
Steps to Reproduce:
1. Install systemtap java-1.6.0-openjdk java-1.6.0-openjdk-devel java-1.6.0-openjdk-debuginfo
2. stap -L 'hotspot.*' > /dev/null
3. See the messages in the "actual results" section
Actual results:
semantic error: not accessible at this address (0x515136): identifier '$arg2' at /usr/share/systemtap/tapset/x86_64/hotspot.stp:438:32
source: class = user_string_n($arg1, $arg2);
^
semantic error: not accessible at this address (0x515136): identifier '$arg6' at :440:30
source: sig = user_string_n($arg5, $arg6);
^
semantic error: failed to retrieve location attribute for local 'arg8' (dieoffset: 0x3c5adc0): identifier '$arg8' at :442:10
source: size = $arg8;
^
semantic error: not accessible at this address (0x5170b7): identifier '$arg2' at :456:32
source: class = user_string_n($arg1, $arg2);
Expected results:
All the probe point arguments available in the hotspot tapset should be available. There shouldn't be any "semantic error" messages.
Additional info:
The probe hotspot.object_alloc has:
size = $arg3;
that should be $arg4 for size according to http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html. However, when this is corrected get:
semantic error: not accessible at this address (0x59d460): identifier '$arg4' at :117:10
source: size = $arg4;
^

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Created attachment 435138[details]
try calculation of size in tapset, not source
I had the same idea as the one from comment #24. We are already using $HeapWordSize in jstack.stp, so this should work. This is what I am currently building (against upstream icedtea6 on fedora 13 i686, gcc-4.4.4-13.fc13.i686). But won't know the results till tomorrow morning (slow laptop).

Ok, so there are two issues with this testcase:
1) one 4.4 and earlier specific - only 4.5+ uses alias oracle to disambiguate
in *true_dependence and so store to (mem:SI (...) %sfp-8) invalidates various
MEMs from the cselib hash table. As %sfp (spill slots) aren't addressable,
in 4.5+ rtx_refs_may_alias_p will say the two mems can't alias if
one is %sfp and the other is not. While obviously backporting all the
aliasing changes is out of the question, perhaps we could consider just
special casing this %sfp vs. non-%sfp if MEM_EXPR, MEM_OFFSET and MEM_SIZE is
present on both MEMs. Either it could be done at the end of
true_dependence/canon_true_dependence (most risky), or e.g. in a new
cselib_canon_true_dependence which would do the same as canon_true_dependence,
just do this extra disambiguation and call it only from cselib, only only from
cselib when used in var-tracking.
2) the other issue is similar to the * 8 issue discussed on x86-64 earlier.
This time it is (zero_extend:SI (something:HI)) vs.
(and:SI (something:SI) (const_int 0xffff)) which again would need to be hashed
using the same hash and compared equal in cselib.

I have installed the rpms from this build. The following smoke test that originally demonstrated this problem works:
[wcohen@cannondale java]$ stap -L 'hotspot.*' > /dev/null
[wcohen@cannondale java]$
The JObjectStats example on the following URL provide much more reasonable:
http://icedtea.classpath.org/~vanaltj/stapexamples/

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note

You need to
log in
before you can comment on or make changes to this bug.