[Bug runtime/2738] deref error on ppc64

[Bug runtime/2738] deref error on ppc64

[roland at gnu dot org]

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

Roland McGrath <roland at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|roland at redhat dot com    |
         AssignedTo|roland at redhat dot com    |systemtap at sourceware dot
                   |                            |org

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

[Bug runtime/2738] deref error on ppc64

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2006-06-13 19:55 -------
There was a simple bug in the ppc64 return value support.
It should be fixed with the next elfutils release.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |roland at redhat dot com
                   |redhat dot com              |
             Status|NEW                         |ASSIGNED


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

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

[Bug runtime/2738] deref error on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-06-12 17:23 -------
Here is the $return tvar extractor function in the attached .c file.

    intptr_t addr;
    { // DWARF expression: 0x73
      {
        intptr_t s0;
        s0 = fetch_register (3) + 0L;
        addr = s0;
      }
    }
    THIS->__retvalue = deref (8, addr);

Compared to the ppc64 retval() function, this does one extra round of
dereference.  According the ppc64 ABI [1], r3 should only be dereferenced
for aggregates/unions/longer character strings.  Integers are returned simply
without indirection.  So here we have an ABI misunderstanding.  It may
be a bug in the new $return code handling (thus cc:ing dsmith), or
inadequacy of the elfutils api for this distinction (thus cc:ing roland).

[1] http://freestandards.org/spec/ELF/ppc64/spec/x280.html#RETURN-VAL


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


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

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

[Bug runtime/2738] deref error on ppc64

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-06-12 08:38 -------
Created an attachment (id=1080)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1080&action=view)
stap -p3 generated .c file

attached .c file is generated by stap -p3 a.stp

a.stp is:
probe kernel.function("sys_read").return
{
	printf("%p\n", $return)
}

"stap a.stp" will give an error:
root:/home/root> stap a.stp
ERROR: pointer dereference fault near identifier '$return' at a.stp:3:17
WARNING: Number of errors: 1, skipped probes: 0

objdump of sys_read:
c0000000000b380c <.sys_read>:
c0000000000b380c:	7c 08 02 a6	mflr	r0
c0000000000b3810:	fb 81 ff e0	std	r28,-32(r1)
c0000000000b3814:	fb a1 ff e8	std	r29,-24(r1)
c0000000000b3818:	7c 9c 23 78	mr	r28,r4
c0000000000b381c:	7c bd 2b 78	mr	r29,r5
c0000000000b3820:	f8 01 00 10	std	r0,16(r1)
c0000000000b3824:	f8 21 ff 61	stdu	r1,-160(r1)
c0000000000b3828:	38 81 00 70	addi	r4,r1,112
c0000000000b382c:	48 00 11 e5	bl	c0000000000b4a10 <.fget_light>
c0000000000b3830:	60 00 00 00	nop
c0000000000b3834:	7f a5 eb 78	mr	r5,r29
c0000000000b3838:	7f 84 e3 78	mr	r4,r28
c0000000000b383c:	38 c1 00 78	addi	r6,r1,120
c0000000000b3840:	3b 80 ff f7	li	r28,-9


-- 


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

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

[Bug runtime/2738] deref error on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-06-09 23:32 -------
Please attach a disassembly of the relevant segment of the probed kernel function,
a relevant segment of the "stap -p3 -k" generated C code (the $return fetching
function).  Unless something else is obviously amiss, please assign this probable
elfutils bug to roland.  Bon appetit!


-- 


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

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

[Bug runtime/2738] deref error on ppc64

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-06-09 23:25 -------
(In reply to comment #1)

> Can you try changing it back to retval() and see if that works?  If so, we can
> reclassify this bug as a ppc64 problem with $return.

retval() works.



-- 


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

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

[Bug runtime/2738] deref error on ppc64

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2006-06-09 17:20 -------
FWIW, it's nice to see that the translator is safely catching this deref without
crashing the system.

Anyway, a recent change here was to use $return to get the task struct instead
of retval(), as per bug #1132.  This works fine for me on i686 and x86_64.

Can you try changing it back to retval() and see if that works?  If so, we can
reclassify this bug as a ppc64 problem with $return.

-- 


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

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