This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: RIP-relative addressing bug
- From: Prasanna S Panchamukhi <prasanna at in dot ibm dot com>
- To: drepper at redhat dot com, roland at redhat dot com, Jim Keniston <jkenisto at us dot ibm dot com>, SystemTAP <systemtap at sources dot redhat dot com>, Andi Kleen <ak at muc dot de>
- Date: Wed, 2 Mar 2005 20:02:44 +0530
- Subject: Re: RIP-relative addressing bug
- Reply-to: prasanna at in dot ibm dot com
>> I don't like the approach of kernel communicating with a user level
>> program to get the correct
>> address to put the probes,
>I doubt this is what Roland meant by disassembling. This certainly
>should be done in the kernel.
>And it really is not that hard, even in the general way. To recognize
>RIP instruction it is only necessary to skip over prefixes and the
>actual instruction bits. These are simple tables which can be
>automatically generated. Then determine whether the instruction uses a
>modr/m byte and if yes, whether this together with the REX prefix
>indicate that the addressing mode is RIP based.
>It's not necessary to know what the instruction actually does. The
>transformation can be done without this information.
AFAIK lots of code will be required to identify whether the
instruction (instruction on which probepoint is placed) is using
RIP-relative addressing.
According to the AMD64 manuals, RIP-relative addressing is used
if and only if mod =0 and r/m =5 in the ModRM byte.
The ModRM bytes always follows the opcode bytes and opcode byte
might contain prefix. In order to check the ModRM byte we need to
decode the whole instruction including prefix.
GDB also decodes the instructions ( see gdb/i386-dec.c file).
Rewritting this part will to be lots of code again.
Reuse of GDB code will be helpful, but we(IBM) cannot send GDB code
files as a patch to LKML.
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>