From: "guij at cn dot ibm dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Subject: [Bug translator/2438] Can't resolve $fd argument for sys_readv and sys_writev on ppc64
Date: Mon, 24 Apr 2006 09:07:00 -0000 [thread overview]
Message-ID: <20060424090732.11609.qmail@sourceware.org> (raw)
In-Reply-To: <20060309040316.2438.hien@us.ibm.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.
next prev parent reply other threads:[~2006-04-24 9:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-09 4:03 [Bug translator/2438] New: " hien at us dot ibm dot com
2006-04-15 5:45 ` [Bug translator/2438] " aoliva at sourceware dot org
2006-04-24 9:07 ` guij at cn dot ibm dot com [this message]
2006-04-24 9:08 ` guij at cn dot ibm dot com
2006-04-26 6:19 ` guij at cn dot ibm dot com
2006-05-08 15:17 ` fche at redhat dot com
2006-05-09 1:48 ` guij at cn dot ibm dot com
2006-05-09 19:26 ` fche at redhat dot com
2006-05-23 5:39 ` aoliva at sourceware dot org
2006-05-23 12:49 ` fche at redhat dot com
2006-05-23 23:59 ` aoliva at sourceware dot org
2007-05-08 18:51 ` fche at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060424090732.11609.qmail@sourceware.org \
--to=sourceware-bugzilla@sourceware.org \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).