Add new types of branch, in a client

[algra...@gmail.com]

Without rebuilding the DynamoRIO core, is there a way for a client to tell DR about instructions that should be treated as branches?

The situation is that the block instrumentation callback gets a block which has some instruction, classified as say OP_xx, OP_sys, OP_nop or similar, and the client wants to tell DR this is a branch, and how to calculate the target.

Ideally, there would be some way of adding a pre-decoding step so that DR would know on first encountering the block, that this instruction terminates it, and not even attempt to decode any more following instructions before calling the instrumentation callback.

[sharma...@google.com]

Hi,

If I understand correctly, your goal is to terminate basic block fragments early.

A similar case that comes to mind is: we actively split the basic block so that each scatter/gather instr is in its own separate fragment: https://github.com/DynamoRIO/dynamorio/blob/8092f319fe7ea7b728dc968a25c771e80a52f912/ext/drx/drx.c#L2401. In the app2app phase, we delete a suffix of app instrs in the fragment, which causes a new fragment to be built for the later app instrs.

Does this help? I'm not certain I understand your use-case though.

> the client wants to tell DR this is a branch, and how to calculate the target

Do you mean you want to convert some app instr into a branch?

Abhinav

[Derek Bruening]

If you truncate the block as Abhinav said and then append a (known, regular) unconditional jump as an app instruction in the app2app phase with the target of this new branch, DR should do what you want with respect to control flow.  If trace superblocks are enabled and the unknown branch is conditional it gets more complicated as DR doesn't know how to invert the direction of the branch to stitch together the blocks: so you may have to disable traces (superblock traces in the core, as opposed to address traces from drmemtrace) unless you can express the condition in terms of other, known branches.  You may also want to use the emulation API to bind the unknown instruction and the inserted jump so that other tools treat them correctly.

Xref the spirit of https://github.com/DynamoRIO/dynamorio/issues/57 though it mostly talks about figuring out the length of x86 instructions.

--
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/d3b33431-c9fd-46ae-922b-d3811a7513a7n%40googlegroups.com.

[algra...@gmail.com]

Thanks, that works for me - do whatever semantics for the new branch instruction, remove the rest of the block and append a freshly created branch instruction that DR understands.

Hopefully, having predecoded the rest of the block (after the instruction that we now know to be a branch) doesn't have any bad consequences. I guess it is possible that DR could have wandered quite far into a literal pool or even crossed a page boundary and hit a fault, but so far that hasn't happened.

(Was the link to code.google.com in that github issue meant to point to more details? It seems to go straight back to github.)