Don't hardcode vex register offsets
rhelmot opened this issue · 5 comments
We've been advised by the valgrind people that those offsets are not meant to be stable across platforms, or even across compilers. The correct solution is to have a method in pyvex that extracts the current platform's offsets from libvex (this can be via a function in pyvex_native that simply does a bunch of offsetof calculations) and if pyvex is available at import time, use that to populate the register fields.
This will drastically simplify the maintenance of archinfo.
Can I assume you mean "the offsets into the simulated register file"?
While I'm not quite clear on why those would change randomly, we'll need to make sure to tell people to use that when writing spotters against a libvex-supported architecture. CC @Nilocunger
They absolutely can change randomly, mostly because of alignment issues - at one point there was an issue where it would change if you compiled with gcc vs clang because gcc will only align double types to 4 bytes by default.
For python-based lifters it's wayyyy less of a problem, and those can be hardcoded in archinfo.
This issue has been marked as stale because it has no recent activity. Please comment or add the pinned tag to prevent this issue from being closed.
I believe this is fixed!