This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: x86_64 RIP-relative addressing bug
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: 03 Mar 2005 12:30:23 -0800
- Subject: Re: x86_64 RIP-relative addressing bug
- Organization:
- References: <200503031428.j23ESuHM028713@magilla.sf.frob.com>
On Thu, 2005-03-03 at 06:28, Roland McGrath wrote:
> Sorry I didn't answer all the particular points you folks raised on
> Wednesday. I grew weary of the protracted discussion, and instead spent a
> couple of hours writing the instruction analyzer function and testing it.
>
"The person who says it cannot be done should not interrupt the person
who is doing it." -- Chinese proverb :-}
I'm looking at this. So far, the only thing that looks wrong is that
you assume that every instruction that uses RIP-relative addressing
includes an SIB byte. Of all the RIP instructions I've looked at, none
has included an SIB byte. This should make your address-of-displacement
off by one (usually, perhaps always). I haven't run a kernel with this
patch yet, so I can't verify that it's actually broken.
Also, in arch_copy_probe() (or before you call it), I'd prefer that you
verify (e.g., using long arithmetic) that the adjusted displacement does
indeed fit in 4 bytes.
One last thing to remember when we add support for probing user-mode
programs: If the app was built with -m32, then what looks like a REX
prefix (40-4f) could actually be an inc or dec opcode. (There are
undoubtedly other issues with non-64-bit modes, but that's the only one
I know that's relevant here.)
Nice job.
Jim