DynamoRIO / DynamoRIO/dynamorio
mixed-mode clients
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on June 22, 2012 15:34:45_
if we finish issue #49 and have 64-bit DR controlling both the wow64 and 32-bit
portions of a 32-bit app on a 64-bit windows kernel we then have some
questions about how clients would operate in such a mixed-mode environment.
first, do we only support a 64-bit client that itself handles mixed-mode,
or do we support two clients, one 64-bit and one 32-bit, with each seeing
just their code stream? that seems weird to me but it seems to be what Pin
does for mixed-mode. if we went the route of 2 clients, xref issue #147 for
similar questions on how to specify 2 clients (but there for multi-arch
app sequences).
xref PR 240257 "support 32-bit clients on wow64?" but that was focused on
how to support a 32-bit client with 64-bit DR which we may decide we don't
want to do.
how do we resolve the conflict of a 32-bit app being configured for
both 64-bit DR and 32-bit DR? 64 wins I guess. should document it.
the client needs to know whether the bb or trace instrlist it's being
handed is 32-bit or 64-bit code. our IR is pretty cross-platform, so it's
more about knowing what instrumentation is legal to add. get_x86_mode()
should be sufficient since it should identify the mode of all the app
instrs, or could just query the mode of the 1st instr in the list, since
we require a whole fragment to be all one mode.
for clean calls out of 32-bit app code, should we always do a mode switch
and assume the clean call target is 64-bit? (this is of course assuming
we go the route of a 64-bit client seeing all the code.)
note that in the past I measured 100 cycles as the cost for a round-trip
mode switch.
_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=828_
Contributor guide
Assessment
This issue has not been assessed yet.