[Bug translator/2438] New: Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[Bug translator/2438] New: Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[hien at us dot ibm dot com]

stap can't resolve the $fd argument for the sys_readv and sys_writev on the
RHEL4 U3 ppc64. No problem seen on the i686.

-- 
           Summary: Can't resolve $fd argument for sys_readv and sys_writev
                    on ppc64
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: hien at us dot ibm dot com


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[aoliva at sourceware dot org]

------- Additional Comments From aoliva at sourceware dot org  2006-04-15 05:45 -------
What does the debug info for these functions look like?  I suspect this may be
fixed in U4, with the backport of variable tracking and location lists for
variables, but I don't have easy access to a RHEL4 U3 ppc64 box to compare with
it.  Also, I don't know whether stap actually supports location lists.  Here's
what I get from readelf -w, using GCC trunk:

 <1><70df3d>: Abbrev Number: 78 (DW_TAG_subprogram)
     DW_AT_external    : 1
     DW_AT_name        : (indirect string, offset: 0x41d64): sys_readv
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 601
     DW_AT_prototyped  : 1
     DW_AT_type        : <70440b>
     DW_AT_low_pc      : 0xc0000000000c783c
     DW_AT_high_pc     : 0xc0000000000c7900
     DW_AT_frame_base  : 0x111a7c       (location list)
     DW_AT_sibling     : <70e01a>
 <2><70df63>: Abbrev Number: 67 (DW_TAG_formal_parameter)
     DW_AT_name        : fd
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 600
     DW_AT_type        : <704124>
     DW_AT_location    : 0x111ab4       (location list)

    00111ab4 c0000000000c783c c0000000000c784c (DW_OP_reg3)
    00111ab4 c0000000000c7850 c0000000000c7868 (DW_OP_reg3)
    00111ab4 <End of list>

RHEL4 U4's GCC generates equivalent debug info.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at sourceware dot org
             Status|NEW                         |WAITING


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[guij at cn dot ibm dot com]

------- Additional Comments From guij at cn dot ibm dot com  2006-04-24 09:07 -------
I met the same problem on my RHEL4U2 ppc64/2.6.16.9. i.e. sys_readv
is defined as:
  sys_readv(unsigned long fd, const struct iovec __user *vec, 
    unsigned long vlen)
but $fd cannot be resolved while both $vec and $vlen are ok.

The error message looks like:
 probe sys_readv@fs/read_write.c:599 pc=0xc0000000000b3f54
 semantic error: unresolved target-symbol expression: identifier '$fd'
   at a.stp:3:8

I did some debugging and thought the probable reason is: 
the instruction at the probe address(0xc0000000000b3f54) will modify 
the register(r3) which contains $fd, thus make related location list entry 
invalid. As a result, the effort to resolving $fd will fail even if such
DW_AT_location entry for $fd exists in .debug_loc section.

Here are the details.

I use "readelf -wi" to get:

 <1><60a219>: Abbrev Number: 73 (DW_TAG_subprogram)
     DW_AT_sibling     : <60a314>
     DW_AT_external    : 1
     DW_AT_name        : (indirect string,offset: 0x3bb14):sys_readv
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 599
     DW_AT_prototyped  : 1
     DW_AT_type        : <6026c4>
     DW_AT_low_pc      : 0xb3f44
     DW_AT_high_pc     : 0xb4004
     DW_AT_frame_base  : 0x12f94c        (location list)
 <2><60a23f>: Abbrev Number: 75 (DW_TAG_formal_parameter)
     DW_AT_name        : fd
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 598
     DW_AT_type        : <6023ef>
     DW_AT_location    : 0x12f984        (location list)
 <2><60a24e>: Abbrev Number: 75 (DW_TAG_formal_parameter)
     DW_AT_name        : vec
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 598
     DW_AT_type        : <607659>
     DW_AT_location    : 0x12f9ba        (location list)

The corresponding DW_AT_location entries in .debug_loc is 
(by eu-readelf --debug-dump=loc):
 [12f94c]  0x00000000000011a8..0x00000000000011c8 [   0] reg1
           0x00000000000011c8..0x0000000000001268 [   0] breg1 160
 [12f984]  0x00000000000011a8..0x00000000000011b8 [   0] reg3
           0x00000000000011bc..0x00000000000011d4 [   0] reg3
 [12f9ba]  0x00000000000011a8..0x00000000000011cc [   0] reg4
           0x00000000000011cc..0x00000000000011e4 [   0] reg28
           0x00000000000011e4..0x00000000000011f8 [   0] reg4
           0x0000000000001234..0x0000000000001268 [   0] reg4

The runtime base address is 0xc0000000000b2d9c, thus the valid address 
range for $fd is (0xc0000000000b3f44, 0xc0000000000b3f54). 

Unfortunately, the probe address is exactly the upper limit and thus
invalid. As a result, the elfutils interface dwarf_getlocation_addr() 
will return failure and dwflpp::translate_location() in systemtap will 
throw the semantic error.

I use "objdump -D" to get the disassembly code around sys_readv:

c0000000000b3f44 <.sys_readv>:
c0000000000b3f44:       7c 08 02 a6     mflr    r0
c0000000000b3f48:       fb 81 ff e0     std     r28,-32(r1)
c0000000000b3f4c:       fb a1 ff e8     std     r29,-24(r1)
c0000000000b3f50:       7c 9c 23 78     mr      r28,r4
c0000000000b3f54:       78 63 00 20     clrldi  r3,r3,32
c0000000000b3f58:       7c bd 2b 78     mr      r29,r5
c0000000000b3f5c:       f8 01 00 10     std     r0,16(r1)
c0000000000b3f60:       f8 21 ff 61     stdu    r1,-160(r1)
c0000000000b3f64:       38 81 00 70     addi    r4,r1,112
c0000000000b3f68:       48 00 0b 41     bl      c0000000000b4aa8 <.fget_light>
c0000000000b3f6c:       60 00 00 00     nop
c0000000000b3f70:       7f a5 eb 78     mr      r5,r29
c0000000000b3f74:       7f 84 e3 78     mr      r4,r28
c0000000000b3f78:       38 c1 00 78     addi    r6,r1,120

Here, the instruction at 0xc0000000000b3f54 modifies incoming argument 
register r3, that's why the valid address range for $fd is 
(0xc0000000000b3f44, 0xc0000000000b3f54).

In comparison, the address range for the second argument $vec is 
(0xc0000000000b3f44, 0xc0000000000b3f68), and the probe 
at 0xc0000000000b3f54 with reference to $vec succeeds.


-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[guij at cn dot ibm dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guij at cn dot ibm dot com


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[guij at cn dot ibm dot com]

------- Additional Comments From guij at cn dot ibm dot com  2006-04-26 06:19 -------
It seems such case cannot be avoided completely. In powerpc, first
arguments are always passed in registers, and there's no reason
for the compiler to refuse to put a modification instruction at the 
probe address.

How about fixing it like:

In ppc64, use
  dwarf_getlocation_addr(attr, pc - module_bias - 4, &expr,&len,1)
instead of
  dwarf_getlocation_addr(attr, pc - module_bias, &expr,&len,1))

Here, 4 is sizeof(kprobe_opcode_t).

The reason is: 

the instruction at the "pc" address will modify the incoming argument 
register therfore make related location list entry invalid, while it 
was still valid at the preceding address "pc-4".

Since our pre-handler will be executed before this instruction
at "pc", the location list entry should also be valid at that time.

But elfutils has no idea about the difference of the inserted handler
and the original instruction, we have use this trick to tell elfutils:
"give me the location-list entry, as long as it is valid before me".

I've tried it on my ppc64 box and it works. 

Any comments?

-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-05-08 15:17 -------
(In reply to comment #3)
> It seems such case cannot be avoided completely. In powerpc, first
> arguments are always passed in registers, and there's no reason
> for the compiler to refuse to put a modification instruction at the 
> probe address.

You mean, there is no need to look for a prologue end?  Yes, we would
prefer not to, but that requires correct location list information from
the compiler to cover the function.


> the instruction at the "pc" address will modify the incoming argument 
> register therfore make related location list entry invalid, while it 
> was still valid at the preceding address "pc-4".

This sounds like a compiler bug.
 
> Since our pre-handler will be executed before this instruction
> at "pc", the location list entry should also be valid at that time.

The definition of the location list entry for an instruction address X
is that, at the beginning of the execution of that instruction, the
respective variables are at their respective locations.  So it should not
matter how large the breakpoint instructions are, or what the instruction
at X would have done.

Roland/Alex, please clarify / correct me.


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


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[guij at cn dot ibm dot com]

------- Additional Comments From guij at cn dot ibm dot com  2006-05-09 01:48 -------
(In reply to comment #4)
> (In reply to comment #3)
> > It seems such case cannot be avoided completely. In powerpc, first
> > arguments are always passed in registers, and there's no reason
> > for the compiler to refuse to put a modification instruction at the 
> > probe address.
> You mean, there is no need to look for a prologue end?  Yes, we would
> prefer not to, but that requires correct location list information from
> the compiler to cover the function.
> 
No, I don't mean there is no need to look for a prologue end. I just want 
to say the first instruction (X) after the prologue may probably modify 
the argument register, thus the location list entry will be inavailable.
Since our prehandler is executed before (X), thus we can use its preceding
one (X-4) to ask for the location list entry. 
In the code of sys_readv, I think 0xc0000000000b3f50 is (X-4) the prologue end
and 0xc0000000000b3f54 is (pc) the first instruction after the prologue as
follow. Sorry if I am wrong with something.

c0000000000b3f44 <.sys_readv>:
c0000000000b3f44:       7c 08 02 a6     mflr    r0
c0000000000b3f48:       fb 81 ff e0     std     r28,-32(r1)
c0000000000b3f4c:       fb a1 ff e8     std     r29,-24(r1)
c0000000000b3f50:       7c 9c 23 78     mr      r28,r4
c0000000000b3f54:       78 63 00 20     clrldi  r3,r3,32
c0000000000b3f58:       7c bd 2b 78     mr      r29,r5
...

-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-05-09 19:26 -------
(In reply to comment #5)
> [...] I just want 
> to say the first instruction (X) after the prologue may probably modify 
> the argument register, thus the location list entry will be inavailable.

It should not be unavailable.  The compiler should spell out where the arguments
are for all instructions.

> Since our prehandler is executed before (X), thus we can use its preceding
> one (X-4) to ask for the location list entry.

That would only make sense if the location list information for address X was
built to represent the *after-image* of the instruction.  I believe otherwise,
that the information represents the state *just before* the instruction would
be executed at address X.  Therefore, using the location list for address X,
for a probe at address X, would be exactly correct.

If for some reason the data does not match this intent, then there is 
probably a compiler bug.


-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[aoliva at sourceware dot org]

------- Additional Comments From aoliva at sourceware dot org  2006-05-23 05:38 -------
I've just checked in a patch for GCC that should fix this problem.  It's
revision 114013 in the GCC SVN repository.  It was approved for the trunk so
far, so it should make to GCC 4.2.

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114013

-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-05-23 12:49 -------
Alex, is this patch also backported for RHEL4-stream gcc 3.4 ?

-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[aoliva at sourceware dot org]

------- Additional Comments From aoliva at sourceware dot org  2006-05-23 23:59 -------
Yes, kind of.  I twas actually first implemented there, and then trivially
forward-ported to mainline.

-- 


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

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

[Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-05-08 19:50 -------
done

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


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

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