How to create a valid move register value to absolute memory address instr ?

58 views
Skip to first unread message

TOMYUE

unread,
Mar 15, 2024, 6:13:53 AMMar 15
to DynamoRIO Users
Hi everyone, sorry to bother.

I wonder what's the right way to create a valid move register value to absolute memory address instr?

I now want to rewrite the `kmovq %rbx -> %k0` into `movq %rbx -> address of mcontext.opmask[0]` and I use the following code to create a new instr to achieve this, but got "usage error : encode error: rip-relative reference out of 32-bit reach" when running
Screenshot 2024-03-15 at 18.08.28.png
I have tried to mimic the opmask register save/restore instr written in emit_utils in my own rewrite instr implementation and got "Not implemented xxxx" error as the following snapshots showScreenshot 2024-03-15 at 18.07.36.png
So I want to know what's the correct way to create such an instr to successfully move the value in a gpr(e.g. `rbx`) to the memory address that holds the opmask register value(e.g. `k0`), thanks a lot!🙏🏻

Derek Bruening

unread,
Mar 15, 2024, 4:00:50 PMMar 15
to TOMYUE, DynamoRIO Users
Several comments:
  1. Please see the docs for opnd_create_abs_addr() https://dynamorio.org/dr__ir__opnd_8h.html#ab73fb113359aaee37844b2592917598d which say that if the address is > 2^32 then "Such an operand can only be guaranteed to be encodable in absolute form as a load or store from or to the rax (or eax) register. It will automatically be converted to a pc-relative operand (as though opnd_create_rel_addr() had been called) if it is used in any other way.".  The x86 ISA only provides a 64-bit address immediate for the rax register, so your attempt to use rbx has to become rip-relative.  Most DR-allocated heap is not guaranteed 32-bit-offset reachable from the cache, including the mcontext: see https://dynamorio.org/using.html#sec_64bit_reach.
  2. Are you using thread-private caches?  If not, caches are thread-shared, and your recording of the absolute address of one particular thread's mcontext will be the wrong location for other threads.
  3. I'm guessing that what you want is to have the drreg extension library updated to include opmask register saving and restoring?  That is a feature that unfortunately does not yet exist, though there was some work toward it that did not quite get merged: see https://github.com/DynamoRIO/dynamorio/issues/3844.  If you would like to pick that up and merge and improve it that would be appreciated!

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/d05f3215-28a5-4422-a014-1422a2962d0dn%40googlegroups.com.

TOMYUE

unread,
Mar 18, 2024, 9:57:31 AMMar 18
to DynamoRIO Users
Thanks very much! The third comment you mentioned is precisely part of what I need, I've built and tried that branch's drreg on 20.04 ubuntu machine, though it failed to successively build because some invalid type argument, it's implementation is a great help for me. I'll try to pick that up and extend it to support opmask register saving and restoring

I have another question to ask.
Is there a mechanism or feature in DynamoRIO that can implement the following scenario: instructions to be executed in a code cache include (using x86_64 assembly as an example):
```
vptestmb {%k0} %ymm17 %ymm17 -> %k2
vpcmpb {%k2} $0x00 %ymm17 (%rsi)[32byte] -> %k1
vmovdqu64 {%k0} (%rsi)[32byte] -> %ymm19
.....
```
During the construction of this `instrlist`, I want to insert an instruction `kmovq %k{idx}, mem_addr` after each instruction that uses a mask register as the destination operand, to store the current value of `%k{idx}` in a memory location somewhere in the current address space. Then, when the execution flow returns from the code cache to `d_r_dispatch`, I can retrieve the value stored at that memory address in the dispatch.c file or interp.c file, .etc?

I am looking for any available implementations or examples that I can refer to. Thank you extremely much!

Abhinav Sharma

unread,
Mar 18, 2024, 10:48:08 AMMar 18
to DynamoRIO Users
Hi,

> Then, when the execution flow returns from the code cache to `d_r_dispatch`, I can retrieve the value stored at that memory address in the dispatch.c file or interp.c file, .etc?

Retrieve the value for what purpose? If it's just for offline analysis, then you can instead dump the data to a file like the drmemtrace tracer does. drmemtrace is fairly complex, but some good example pointers may be: the clean_call[1] routine that outputs the trace data to a file, instrument_memref[2] that generates instrumentation to buffer data before it's written to file, and other trace output logic[3].

On the other hand, if you want to retrieve the values _during_ application execution (perhaps because some instrumentation logic depends on this data), you can again use something like drmemtrace's clean_call[1] to process the buffer of values when it's full.

In your question, you mentioned "when the execution flow returns from the code cache to `d_r_dispatch` ... in the dispatch.c file or interp.c file, .etc": I assume you were thinking of retrieving the data in some instrumentation event instead? In general, clients do not have any control over when the instrumentation events are invoked, so it is better to use a mechanism like [1] which you can rely on to be invoked when data is ready to be retrieved/processed. Or is there any other reason you'd like to do this in an instrumentation event?


Let me know if this helps.

Abhinav

Abhinav Sharma

unread,
Mar 19, 2024, 7:06:36 AMMar 19
to DynamoRIO Users
The memval_simple client is relevant too, and perhaps is a better example. See the implementation and uses of trace_fault[1] and drx_buf_create_trace_buffer[2].


Abhinav

Abhinav Sharma

unread,
Mar 19, 2024, 8:31:05 AMMar 19
to DynamoRIO Users
Also see the Buffer Filling API (https://dynamorio.org/page_drx.html#sec_drx_buf) documentation.

Abhinav

Reply all
Reply to author
Forward
0 new messages