DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.63k stars 557 forks source link

support using decode routines from the full DR library without initialization #2499

Open derekbruening opened 7 years ago

derekbruening commented 7 years ago

This issue is about having DR's decode routines automatically invoke standalone init if called prior to DR init.

This use case is what's driving this issue: creating a library that uses drdecode only, but that is able to be used both in a native app and in an app running under full DR. This does not work because drdecode relies on replacing heap_alloc with a version that calls malloc.

The initial workaround is to link the library with full DR, but that doesn't work unless the library forces all linking apps that use it but don't themselves run under DR to invoke dr_standalone_init().

Having automated standalone init will also make it easier for other standalone uses of DR.

derekbruening commented 1 year ago

Re-opening this as we would like to try to improve the solution.

We have 3 issues:

1) The check in global_heap_alloc() added in PR #2504 is not sufficient: for #5871 in PR #5882 we decode a jump which with one source and no dests requires no allocation, yet without init we hit problems on Windows with instr_set_target() trying to check the interception vector. In PR #5882 I added another implicit init inside instr_init() to solve this.

2) There is no call to standalone_exit(). This can lead to bugs: even if today drdecode doesn't use any state and its standalone_init() call doesn't use any state that really needs cleanup, we could add some later, so this is fragile. Possible ways to add cleanup include assuming libc and using atexit(), or using ELF destructors (but this won't work for a pure-static exe, or on Windows or other platforms unless we find a similar solution there).

3) These checks in certain init routines are kind of ugly. Can we have a solution similar to 2) above: an ELF constructor?