This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RIP-relative addressing bug


>> 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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]