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
We obviously want to do this for externally-triggered attach (xref issue
38 , issue #725 ). Today's internally-triggered attach ( issue #722 ) assumes
the app has called our init routine up front and that we just need to take
over all the threads later.
Even for regular injection, to handle corner cases of early threads, we
should suspend all the other threads for the duration of DR's init to
satisfy the parts of the init process that assume there are no races.
For the start/stop API, we would want to only support combined
dr_app_setup_and_start(). We would also have to refactor the init and
takeover code to do enough initialization that we can send signals to
threads for takeover, then finish initialization, and only then resume the
threads.
From bruen...@google.com on October 25, 2013 14:46:17
Xref issue #1304 .
We obviously want to do this for externally-triggered attach (xref issue
38 , issue #725 ). Today's internally-triggered attach ( issue #722 ) assumes
the app has called our init routine up front and that we just need to take
over all the threads later.
Even for regular injection, to handle corner cases of early threads, we
should suspend all the other threads for the duration of DR's init to
satisfy the parts of the init process that assume there are no races.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1305
The text was updated successfully, but these errors were encountered: