client interactions with cross-arch execve
From derek.br...@gmail.com on May 23, 2009 10:55:03
With debug build and a 32-bit client, if an app does execve to a 64-bit app, we'll kill the process with a usage error due to the 32-bit client mismatch:
<-- parent 16846 forked child 16903 --> <-- execve /bin/sh --> <Application sh (16903) DynamoRIO usage error : Error opening instrumentation library /work/dr/tot/exports_drmemory/libdrmemory.so: /work/dr/tot/exports_drmemory/libdrmemory.so: wrong ELF class: ELFCLASS32>
We should at least provide an option to turn this into a non-fatal error, to enable using debug build in such situations. In my usage case the execve of 64-bit sh is followed by execve of 32-bit perlbmk, and I'm fine with my client not being loaded into sh, but I do want to be loaded into perlbmk. This is what happens today with a release build, with a non-fatal message:
<Application sh (18109). Unable to load client library: Error opening instrumentation library /work/dr/tot/exports_drmemory/libdrmemory.so: /work/dr/tot/exports_drmemory/libdrmemory.so: wrong ELF class: ELFCLASS32.> <Starting application sh (18109)> <Starting application perlbmk (18110)>
We should consider what model we want to support for clients in such scenarios: specify separate 32-bit and 64-bit clients? Xref all the similar Windows issues: PR 240257, PR 254193, issue #49. Those Windows cases also focus on mixed-mode processes.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=147