Skip to content
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.

Sign up for GitHub

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

Jump to bottom

PC-relative operand support on ARM broken #1835

Closed
derekbruening opened this issue Dec 11, 2015 · 1 comment
Closed

PC-relative operand support on ARM broken #1835

derekbruening opened this issue Dec 11, 2015 · 1 comment
Assignees
@derekbruening
Labels
Component-API OpSys-ARM

Comments

@derekbruening
Copy link
Contributor

For the ARM port (#1551) we half-added PC-relative operand support, changing the headers to say that opnd_create_rel_addr() works on ARM, when in fact it will fail to encode. Plus, we never made opnd_is_rel_addr() supported on ARM in the headers or implementation.

We should either change the headers to not support REL_ADDR_kind at all, or we should implement full support via the query routines and in the encoder. The encoder already handles opnd_is_mem_instr() and rel addr opnd support is very, very similar, so I would vote for adding it.

Note that trying to auto-magically take a tool opnd marked as base-disp that has a PC base and re-relativize it is a whole other kettle of fish as that requires register spilling and is covered by #1834.
@derekbruening derekbruening self-assigned this Dec 11, 2015
@derekbruening
Copy link
Contributor Author

One problem is that rel-addr instrs won't show up as reading the PC b/c they have no explicit PC opnd.
I guess we just document it, b/c we're not decoding into rel-addr: only synthetic tool instrs will be marked that way and we'll assume the tool can explicitly deal with them, even if they're added as app instrs.

derekbruening added a commit that referenced this issue Feb 20, 2018
@derekbruening
i#1309 win8+ threads: use NtCreateThreadEx for external nudges
f27c13f 
Changes the libutil nudge code to use NtCreateThreadEx on Win8+.

For a test, enables the client.nudge_test test, part of i#120: enable
.runall tests on Windows.  Here I added a new app win32.infloop to parallel
linux.infloop, rather than launching calc.exe or notepad.exe like we did in
the past (not yet tackling systemwide injection here).  It has a MessageBox
with a title containing the pid, allowing us to use tools/closewnd with a
unique target name for a clean and race-free exit.  win32.infloop also has
a 3-minute timeout to avoid leaving stale processes behind in case of
issues closing it externally.

Revamped runall.cmake to work on Windows, using "ping" to sleep,
updating nudge and close commands, removing stale pid files, etc.

Ported suite code to use run_in_bg on Windows as well as Linux,
but with the pidfile coming from drrun.

Fixes #1309
Fixes #1432
Issue: #120, #1835
@derekbruening derekbruening mentioned this issue Feb 20, 2018
Merged
derekbruening added a commit that referenced this issue Feb 20, 2018
@derekbruening
i#1309 win8+ threads: use NtCreateThreadEx for external nudges (#2840)
b726e89 
Changes the libutil nudge code to use NtCreateThreadEx on Win8+.

For a test, enables the client.nudge_test test, part of i#120: enable
.runall tests on Windows.  Here I added a new app win32.infloop to parallel
linux.infloop, rather than launching calc.exe or notepad.exe like we did in
the past (not yet tackling systemwide injection here).  It has a MessageBox
with a title containing the pid, allowing us to use tools/closewnd with a
unique target name for a clean and race-free exit.  win32.infloop also has
a 3-minute timeout to avoid leaving stale processes behind in case of
issues closing it externally.

Revamped runall.cmake to work on Windows, using "ping" to sleep,
updating nudge and close commands, removing stale pid files, etc.

Ported suite code to use run_in_bg on Windows as well as Linux,
but with the pidfile coming from drrun.

Fixes #1309
Fixes #1432
Issue: #120, #1835
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@derekbruening derekbruening

Labels
Component-API OpSys-ARM
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@derekbruening