-
Notifications
You must be signed in to change notification settings - Fork 596
i#7496 eret continuity: Set branch target using get_next_trace_pc() #7639
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
Conversation
…branch Adds logic in the drmemtrace scheduler to set the branch target of syscall- and switch-final indirect branch instructions (e.g., eret on AArch64) to the next instruction in the thread's trace. - The syscall-trace-final indirect branch now points to the next instruction as seen on the thread shard, which may be the syscall-fallthrough or the syscall instruction again for auto-restart syscalls. - The context-switch-trace-final indirect branch points to the next instruction of the new input. - When there is a syscall trace immediately followed by a switch trace, the syscall-final indirect branch still points to next instruction as seen on the thread shard. When reading the kernel trace templates, we discover and record the first instruction of the template, which we present as the next trace pc just prior to the trace's injection. Augments the get_next_trace_pc() implementation to return the next pc in the injected trace, when it is queried in the middle of dynamic injection. Enables invariant checks on the get_next_trace_pc() output during the dynamically injected part of the trace. Adds unit tests for: - analyzer parallel mode with syscall injection - scheduler syscall+switch injection that has some idles - extends existing syscall and switch scheduler tests Issue: #7496
I decided to create a new branch and PR for this approach and abandon #7614. The new logic added here is all different from #7614; scheduler_unit_tests.cpp is the only file that's kind of similar, so if you'd like to see the changes since your last #7614 review of that file, PTAL clients/drcachesim/tests/scheduler_unit_tests.cpp on https://github.com/DynamoRIO/dynamorio/compare/i7496-kernel-ibt-readahead..i7496-set-branch-target. |
Enables PC continuity checks in the invariant_checker that verify control flow continuity of the branch_target marker value to the post-syscall trace pc. Until #7639, the syscall-trace-end branch_target marker always held the syscall-fallthrough pc, but now it holds the pc of the actual next instr in the thread. This solves two previously-unhandled cases: auto-restart syscalls that resume control at the syscall pc itself, and control-transferring syscalls like sigreturn that resume control at some arbitrary pc. Also manually ran the invariant checker on two large internal app traces (x86 and aarch64), and confirmed that no unexpected invariant errors were reported. Issue: #7496
Adds logic in the drmemtrace scheduler to set the branch target of syscall- and switch-final indirect branch instructions (e.g., eret on AArch64) to the next instruction in the thread's trace.
We use the memtrace_stream_t::get_next_trace_pc() API to discover the next trace pc that will be seen on a thread trace.
When reading the kernel trace templates, we discover and record the first instruction PC of the template, which we present as the next trace PC just prior to the trace's injection.
Augments the get_next_trace_pc() implementation to return the next pc in the injected trace, when it is queried in the middle of dynamic injection.
Enables invariant checks on the get_next_trace_pc() output during the dynamically injected part of the trace. Enables PC continuity checks in the invariant_checker that verify control flow continuity of the branch_target marker value to the post-syscall trace pc.
Adds unit tests to verify get_next_trace_pc() output, and kernel-trace-final indirect branch target values in various modes of operation:
Also manually ran the invariant checker on two large internal app traces (x86 and aarch64), and confirmed that no unexpected invariant errors were reported.
Issue: #7496