public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "fche at redhat 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, 08 May 2006 15:17:00 -0000	[thread overview]
Message-ID: <20060508151710.28258.qmail@sourceware.org> (raw)
In-Reply-To: <20060309040316.2438.hien@us.ibm.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.

  parent reply	other threads:[~2006-05-08 15:17 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
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 [this message]
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=20060508151710.28258.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).