for -pause_at_*, present app context inside debugger, not tool context

[derekbruening]

From rnk@google.com on September 22, 2011 16:10:18

This feature should roughly mirror --gdb-attach=yes for memcheck. We already have -pause_at_uninitialized/unaddressable, but attaching in this way puts the user a few frames inside of DrMemory tool code. --gdb-attach sets up gdb so that it sees the original application context, ie all of the application registers, xsp, xip, etc, and the user can begin a normal debugging session as if the tool wasn't there.

I have found this really useful for being able to actually print out values when I have say an out of bounds access, for example. If you don't have this, you only get the information the tool gives you, while the debugger allows you to ask more questions.

Original issue: http://code.google.com/p/drmemory/issues/detail?id=600

[derekbruening]

From bruen...@google.com on September 22, 2011 13:15:41

presumably this will build on underlying DR debugger interaction features: https://code.google.com/p/dynamorio/issues/detail?id=532 https://code.google.com/p/dynamorio/issues/detail?id=559

Summary: for -pause_at_*, present app context inside debugger, not tool context

[derekbruening]

From bruen...@google.com on September 22, 2011 13:17:00

xref issue #134

[derekbruening]

From bruen...@google.com on November 12, 2013 09:56:41

we also want the app context for core dumps ( issue #134 ) and deliberate crashes ( issue #1378 )

[derekbruening]

From bruen...@google.com on May 08, 2014 12:32:58

as an initial step here I'm going to put in a local var CONTEXT (using dr_mcontext_to_context() which I recently added) for at least our own use until we have a real debugger interface

[derekbruening]

From bruen...@google.com on May 08, 2014 12:32:58

as an initial step here I'm going to put in a local var CONTEXT (using dr_mcontext_to_context() which I recently added) for at least our own use until we have a real debugger interface