DynamoRIO / DynamoRIO/dynamorio
support auto-decoding an LSB=1 address as Thumb
- Dominant language
- C
- Stars
- 3.2k
- Forks
- 629
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 31
Description
The propposal here is to have the various decode routines on ARM check for
an LSB=1 address and switch to Thumb mode for decoding it, additionally
returning LSB=1 for the next pc. Some other tools like gdb do this. The
logic is that dr_get_proc_address() (and function pointers in source code)
have LSB=1, and the client is likely to try to decode them and won't want to
(or won't remember to) call some routine to drop the LSB. This happens in our tests,
in the drwrap test in particular.
If we don't do this, we should add dr_app_pc_as_decode_target() and callers
must pass dr_get_proc_address() results through that, and then back through
dr_app_pc_as_jump_target() before using as clean call or drwrap replacement
or any kind of callback.
Xref a port-to-ARM original suggestion of storing tags and gencode entry
points w/ LSB=1 which was abandoned: there was more pain there than just
decoding so adding this decode feature won't make us want to go revisit
that decision.
Better to return next_pc w/ LSB=1, which is extra work in the decode
routines b/c have to zero it out for the reading and remember whether has
LSB=1, or to set the thread mode (as opposed to a temporary decode_info_t
setting of Thumb mode only)? If we set the thread mode, I'm worried about
the client doing some decoding during a bb event or module load event
inadvertently changing the app's mode and thus behavior.
Contributor guide
Assessment
This issue has not been assessed yet.