DynamoRIO / DynamoRIO/dynamorio

Provide the starting pc of each application thread

Open
#8,041 1 comment 0 reactions 0 assignees View on GitHub
Component-API Type-Feature
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

**Is your feature request related to a problem? Please describe.**
In my client, I need to record the first application PC that is executed when a new thread spawns. There is currently not an efficient way of doing this.

**Describe the solution you'd like**
`_dcontext_t` has a `next_tag` field which seems to store the first application PC that will be run for any thread that is not the initial thread, but it is currently not exposed. Exposing this would make it much easier to record the first app PC to run: for initial thread, do alternative 3 described below (which is OK because the first block to execute for the initial thread seems to be the first app PC), and for spawned threads, use the `next_tag` field.
The expected API to expose is `app_pc dr_get_next_tag(void *drcontext)`, returning `drcontext->next_pc` for spawned threads. It may be best if it can also return the first app PC instead of 0 for the initial thread properly.

**Describe alternatives you've considered**

1. reading `mcontext` on thread init event and use its `pc` field, but that field seems to be zero at that time so is unusable.
2. intercepting `clone`/`clone3` syscall has the same issue
3. on `drmgr`'s `insertion_func`, run on instrumentation time a one-time recording of the PC, i.e. the first call to the bb_insertion event on the thread is assumed to contain the first app PC. This is however not accurate as later spawned thread may run an already instrumented block at start, so it will mistake later-run basic blocks as the first block that ran on that thread.
4. on `drmgr`'s `insertion_func`, add meta-instructions that records the first PC guarded by a `is_first_pc_reached` flag. This works but is very expensive for achieving a one-shot job.

Contributor guide

Open the contributing guide

Research direction

Start by tracing the _dcontext_t next_tag field and the existing thread-init and drmgr insertion_func entry points. Define the behavior of dr_get_next_tag for spawned and initial threads, then add or update the relevant API coverage so the returned value matches the first application PC.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
tooling
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
56/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.