You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the problem to solve?
I would like to know if some code executing under the control of DR, and specialize the behaviour of that code to DR's presence. For example, if I wanted to verify that DR has taken over all threads of a process, then each thread could execute code along the lines of:
if(!dr_is_enabled()) {
fprintf(stderr, "Not under control of DR!!\n");
}
Why is it important?
This is helpful for testing DR's takeover abilities. This might also be helpful for making some code interact nicely with DR. For example, if there is some tricky optimization in some application that doesn't behave well with DR, then that optimization can be disabled when instrumenting with DR. What are the possible approaches to solving the problem? Applications link with a shared library that exposes a function, e.g. dr_is_enabled. This function always returns false/0. When under the control of DR, DR translates CALLs to the function into MOV $1, %DR_REG_XAX; Which approach is being taken and why? This functionality does not appear to be supported. Support for this feature falls under the category of intentional breaks of transparency, as a means of changing program behavior. Any interesting details or challenges of the implementation? Ensuring that DR can replace calls to shared function. There are two potential ways of going about this, neither of which is mutually exclusive:
Recognize specific CALLs, and replace them. The downside of this approach is that it introduces minor overhead to instruction translation for every CALL. I am not clear on whether or not this plays well with signal delaying / figuring out the app_pc for the translated mov cache_pc.
Pre-populate the code cache hash table lookup function(s) with the app_pc address of the dr_enabled function, and have it target some gencode that does a MOV $1, %DR_REG_XAX; RET;. This approach should tie in transparently with existing code.
This is finished, isn't it? DYNAMORIO_ANNOTATE_RUNNING_ON_DYNAMORIO or RUNNING_ON_VALGRIND should both work. Maybe what's missing is adding documentation?
From peter.goodman on July 30, 2013 12:17:38
What is the problem to solve?
I would like to know if some code executing under the control of DR, and specialize the behaviour of that code to DR's presence. For example, if I wanted to verify that DR has taken over all threads of a process, then each thread could execute code along the lines of:
if(!dr_is_enabled()) {
fprintf(stderr, "Not under control of DR!!\n");
}
Why is it important?
This is helpful for testing DR's takeover abilities. This might also be helpful for making some code interact nicely with DR. For example, if there is some tricky optimization in some application that doesn't behave well with DR, then that optimization can be disabled when instrumenting with DR. What are the possible approaches to solving the problem? Applications link with a shared library that exposes a function, e.g. dr_is_enabled. This function always returns false/0. When under the control of DR, DR translates CALLs to the function into MOV $1, %DR_REG_XAX; Which approach is being taken and why? This functionality does not appear to be supported. Support for this feature falls under the category of intentional breaks of transparency, as a means of changing program behavior. Any interesting details or challenges of the implementation? Ensuring that DR can replace calls to shared function. There are two potential ways of going about this, neither of which is mutually exclusive:
Recognize specific CALLs, and replace them. The downside of this approach is that it introduces minor overhead to instruction translation for every CALL. I am not clear on whether or not this plays well with signal delaying / figuring out the app_pc for the translated mov cache_pc.
Pre-populate the code cache hash table lookup function(s) with the app_pc address of the dr_enabled function, and have it target some gencode that does a MOV $1, %DR_REG_XAX; RET;. This approach should tie in transparently with existing code.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1237
The text was updated successfully, but these errors were encountered: