-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble with ARM Operand-Shift #246
Comments
yes this is a bug. i think the shift should be done on R3, not on PC. how do you think we should fix this issue without having to change the structure of |
Unfortunatly i'm not familiar with the source. From what I can see is, that an operand shift never effects the whole memory operand and it is never applied to the base register. This implies that only the index register can be optionally shifted and so I guess for the moment it should be enough to fix the wrong association from the PC to the mem operand. |
working on a fix now. it seems the only type of shift inside a memory address is left-shift on the last (index) register. do you see any exception to this? thanks. |
it seems the only type of shift in memory operand is left-shift. this issue has been fixed in the note: the |
to be sure, reinstall the core & Python binding like followings if you are on *nix (Linux, OSX, BSD, etc):
|
Yes it seems LSL is the only shift which is applied to the index register (for thumb memory instructions only!). Tested and it works. Thanks for your effort! |
For a more detailed description, see issue capstone-engine#1317. Release 4.0.0 introduced a new field for ARM operands: `operand.mem.lshift`. This field was supposed to be a bug fix for capstone-engine#246. The capstone-engine#246 issue has been fixed in the meantime and the proper shift value was stored in `operand.shift.value`. The 4.0.0 changes created a regression in which `operand.shift.value` was not set for a `tbh [r0, r1, lsl capstone-engine#1]` instruction on ARM and the value was set in a `operand.mem.lshift` field instead. As the regression broke some of users codebase (e.g. in [manticore](trailofbits/manticore#1312) project), we fix it by setting `operand.shift.value` back again. As a result, the shift value is set in two fields: `operand.shift.value` and `operand.mem.lshift`. As the `operand.shift` also stores a `.type` field, we might want to deprecate `operand.mem.lshift` in the future.
* Fixes #1317 - arm thb operand.shift.value For a more detailed description, see issue #1317. Release 4.0.0 introduced a new field for ARM operands: `operand.mem.lshift`. This field was supposed to be a bug fix for #246. The #246 issue has been fixed in the meantime and the proper shift value was stored in `operand.shift.value`. The 4.0.0 changes created a regression in which `operand.shift.value` was not set for a `tbh [r0, r1, lsl #1]` instruction on ARM and the value was set in a `operand.mem.lshift` field instead. As the regression broke some of users codebase (e.g. in [manticore](trailofbits/manticore#1312) project), we fix it by setting `operand.shift.value` back again. As a result, the shift value is set in two fields: `operand.shift.value` and `operand.mem.lshift`. As the `operand.shift` also stores a `.type` field, we might want to deprecate `operand.mem.lshift` in the future. * Add changelog stub
Hello,
i'm having trouble with following instruction:
The following code (taken from the python test examples),
prints (only a part of):
As you can see the logical shift which is performed on R3, is instead associated with operand[0] which is the PC. Is this an intended behavior? I'm aware the the second operand is a memory access and there is no attribute regarding an shift operation but i somehow need to make a proper connection between the shift operation and the index register. I'm not exactly sure if this is a bug or if i'm missing something.
Thank's in advance
The text was updated successfully, but these errors were encountered: