CBR instrumenation

[Igor R]

I'd like to instrument both edges of a CBR.

IUUC, dr_insert_cbr_instrumentation won't help, as I want to insert some specific clean all (or things like dr_save_reg) both at the fallthrough and at the point of the "taken branch", i.e. just before the instruction where the control goes. I can determine statically the both addresses, but how to get the appropriate instruction to use with dr_insert_clean_call? Is it possible at all, as the instruction may be in another BB?

 

Thanks.

[Derek Bruening]

See the sample client cbr.c.

--
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 post to this group, send email to dynamor...@googlegroups.com.
Visit this group at http://groups.google.com/group/dynamorio-users.
For more options, visit https://groups.google.com/d/optout.

[Igor R]

Actually, it seems to be an overkill for my case, as I don't need to adjust the instrumentation dynamically. All I need is to insert the same meta-instructions/clean-call both at fallthrough and at taken branch statically. At fallthrough I can do it directly, just by appending the calls at the bb end, so the only problem is to realyse how to insert them at instr_get_branch_target_pc(instr) address. I tried to do this as follows:

1) in basic block event, if the current instruction is cbr -- store the target address and *copy* the instr_t designating the cbr instruction.

2) in basic block event, if the current instruction's PC equals the target stored above -- analyse the saved instr_t and insert the needed meta-instructions before the current one (which is the target).

 

It seems however that instr_t is not copiable, because an attempt to analyse its operands at (2) seems to produce incorrect results - is it expected behavior?

 

So, is isn't there a simple way to accoplish the above task?

 

I'd appreciate any idea.

[Qin Zhao]

On May 18, 2014 9:18 PM, "Igor R" <boost...@gmail.com> wrote:
>
> Actually, it seems to be an overkill for my case, as I don't need to adjust the instrumentation dynamically. All I need is to insert the same meta-instructions/clean-call both at fallthrough and at taken branch statically. At fallthrough I can do it directly, just by appending the calls at the bb end,

I do not think it is correct.

so the only problem is to realyse how to insert them at instr_get_branch_target_pc(instr) address. I tried to do this as follows:

dr_insert_cbr_instrumentation is the one you should use. In the clean call, you will know if the fall through or branch will take and its target. So basically that clean call is the combination of the two clean calls you want to insert.

[Igor R]

> Actually, it seems to be an overkill for my case, as I don't need to adjust the instrumentation dynamically. All I need is to insert the same meta-instructions/clean-call both at fallthrough and at taken branch statically. At fallthrough I can do it directly, just by appending the calls at the bb end,

I do not think it is correct.

 

Could you please elaborate a bit more? Why isn't it correct? Consider the following:

l1:

  #do_something...

  loop l1;

l2:

  #do_more...

 

The CBR here is "loop" instruction. I'd like to instrument both it's fallthrough (l2) and it's taken branch (l1). To instrument the fallthrough, isn't it enough to insert my instrumentation at BB end (i.e. after "loop")?

 

 

> so the only problem is to realyse how to insert them at instr_get_branch_target_pc(instr) address. I tried to do this as follows:

dr_insert_cbr_instrumentation is the one you should use. In the clean call, you will know if the fall through or branch will take and its target. So basically that clean call is the combination of the two clean calls you want to insert.

 

For some reason, dr_insert_cbr_instrumentation() allows only fixed-signature callback function (doesn't it?) - that's why it's somewhat limiting for my needs, as I have to pass some additional info, like affected registers values.

But given instr_clone(), the approach I described above (i.e. memorizing cbr target address and instrumenting it later) should work.

[Qin Zhao]

On May 19, 2014 10:37 PM, "Igor R" <boost...@gmail.com> wrote:
>>
>> > Actually, it seems to be an overkill for my case, as I don't need to adjust the instrumentation dynamically. All I need is to insert the same meta-instructions/clean-call both at fallthrough and at taken branch statically. At fallthrough I can do it directly, just by appending the calls at the bb end,
>>
>> I do not think it is correct.
>
>  
> Could you please elaborate a bit more? Why isn't it correct? Consider the following:
> l1:
>   #do_something...
>   loop l1;
> l2:
>   #do_more...
>  
> The CBR here is "loop" instruction. I'd like to instrument both it's fallthrough (l2) and it's taken branch (l1). To instrument the fallthrough, isn't it enough to insert my instrumentation at BB end (i.e. after "loop")?
>  
>  

One problem is that the target might also be other branch's target too.

Aonther is problem is when the code is promoted intto trace, the cbr might be inverted.

>>
>> > so the only problem is to realyse how to insert them at instr_get_branch_target_pc(instr) address. I tried to do this as follows:
>>
>> dr_insert_cbr_instrumentation is the one you should use. In the clean call, you will know if the fall through or branch will take and its target. So basically that clean call is the combination of the two clean calls you want to insert.
>
>  
> For some reason, dr_insert_cbr_instrumentation() allows only fixed-signature callback function (doesn't it?) - that's why it's somewhat limiting for my needs, as I have to pass some additional info, like affected registers values.
> But given instr_clone(), the approach I described above (i.e. memorizing cbr target address and instrumenting it later) should work.
>

You can pass extra value via tls.

[Igor R]

> Could you please elaborate a bit more? Why isn't it correct? Consider the following:
> l1:
>   #do_something...
>   loop l1;
> l2:
>   #do_more...
>  
> The CBR here is "loop" instruction. I'd like to instrument both it's fallthrough (l2) and it's taken branch (l1). To instrument the fallthrough, isn't it enough to insert my instrumentation at BB end (i.e. after "loop")?
>  
>  
One problem is that the target might also be other branch's target too.

 

Well, actually any point in a program may also be the target address of one or more branchings, so any clean call (or any DR metainstruction) inserted before an application instruction will always be invoked whenever the flow reaches that instruction, right?

 

 

 

Aonther is problem is when the code is promoted intto trace, the cbr might be inverted.

 

Ok, I see. Could you please provide a link where this issue is explained in details?

Doesn't it affect the code in cbr.c? In particular, in bb_event:

if (insert_taken || insert_not_taken) {
                app_pc fall = (app_pc)decode_next_pc(drcontext, (byte *)src);
                app_pc targ = instr_get_branch_target_pc(instr);

//...

 

 

 

> For some reason, dr_insert_cbr_instrumentation() allows only fixed-signature callback function (doesn't it?) - that's why it's somewhat limiting for my needs, as I have to pass some additional info, like affected registers values.
> But given instr_clone(), the approach I described above (i.e. memorizing cbr target address and instrumenting it later) should work.
>

You can pass extra value via tls.

 

Sorry, I misexplained why it won't work for me. The point is that I have to insert metainstructions *after* the cbr, as I need to analyse the contents of the registers affected by the branching. So in the callback of dr_insert_cbr_instrumentation() I can only memorize the target address and dr_flush_region this address (is this callback considered a clean call, i.e. is flushing code cache permitted there?), and then I can detect this address during the next bb event and add the desired instrumentation. Would it be a workable approach?

 

Thanks!

[Qin Zhao]

On May 20, 2014 5:43 PM, "Igor R" <boost...@gmail.com> wrote:
>>
>> > Could you please elaborate a bit more? Why isn't it correct? Consider the following:
>> > l1:
>> >   #do_something...
>> >   loop l1;
>> > l2:
>> >   #do_more...
>> >  
>> > The CBR here is "loop" instruction. I'd like to instrument both it's fallthrough (l2) and it's taken branch (l1). To instrument the fallthrough, isn't it enough to insert my instrumentation at BB end (i.e. after "loop")?
>> >  
>> >  
>> One problem is that the target might also be other branch's target too.
>
>  
> Well, actually any point in a program may also be the target address of one or more branchings, so any clean call (or any DR metainstruction) inserted before an application instruction will always be invoked whenever the flow reaches that instruction, right?
>  
>  

If you instrument before the cbr, it will only be called for the cbr.

>  
>>
>> Aonther is problem is when the code is promoted intto trace, the cbr might be inverted.
>
>  
> Ok, I see. Could you please provide a link where this issue is explained in details?
> Doesn't it affect the code in cbr.c? In particular, in bb_event:
> if (insert_taken || insert_not_taken) {
>                 app_pc fall = (app_pc)decode_next_pc(drcontext, (byte *)src);
>                 app_pc targ = instr_get_branch_target_pc(instr);
> //...
>

No, the invert happens after the client instrumentation, so cbr.c won't be affected, but if you insert code for fall through, it might be affected.

 
>  
>  
>>
>> > For some reason, dr_insert_cbr_instrumentation() allows only fixed-signature callback function (doesn't it?) - that's why it's somewhat limiting for my needs, as I have to pass some additional info, like affected registers values.
>> > But given instr_clone(), the approach I described above (i.e. memorizing cbr target address and instrumenting it later) should work.
>> >
>>
>> You can pass extra value via tls.
>
>  
> Sorry, I misexplained why it won't work for me. The point is that I have to insert metainstructions *after* the cbr, as I need to analyse the contents of the registers affected by the branching. So in the callback of dr_insert_cbr_instrumentation() I can only memorize the target address and dr_flush_region this address (is this callback considered a clean call, i.e. is flushing code cache permitted there?), and then I can detect this address during the next bb event and add the desired instrumentation. Would it be a workable approach?
>  

Normally, the reg won't be affected by cbr unless special cases like loop instr.
Even that, the effect is statically known. If you want to know hwo the regs are affected by the instr after cbr, it is statically known too if assuming no self modifying code.

> Thanks!

[Igor R]

Normally, the reg won't be affected by cbr unless special cases like loop instr.
Even that, the effect is statically known. If you want to know hwo the regs are affected by the instr after cbr, it is statically known too if assuming no self modifying code.

 

Yes, right. I just wanted to make it generic, instead of assuming I know every effect of each cbr instruction. But in the end of the day, I will probably end up with such a static approach.

BTW, is there a list of all available cbr instructions for both x32 and x64 modes?