Diagnosing pre-main latency in a short-lived macOS child process while preserving its parent

I’m looking for a supported way to investigate startup latency before main() in a short-lived native macOS child process, while preserving its original parent-child relationship.

Environment

• macOS 26.6.2, build 25G83.
• Native arm64 executables.
• The on-disk /usr/lib/dyld contains the identifier dyld-1387; this is a static observation, not independent verification of all runtime shared-cache components.
• The diagnostic runs were started manually from normal macOS Terminal.
• All inputs and target processes are synthetic test fixtures.

Execution structure Test supervisor → Watchdog → Observer → Query

Observer launches Query using posix_spawn(). Query checks a synthetic target process’s identity using Security.framework and produces a fixed 28-byte result.

Observer passes an explicit environment containing only LANG=C and LC_ALL=C. Consequently, exporting DYLD variables in the outer Terminal would not pass them to Query.

Our existing test has a 1000 ms Query deadline and requires empty Query stderr. This is an application-defined acceptance requirement, not a claimed macOS timing guarantee.

Observed results

1. A historical full regression run timed out at approximately 1001 ms, with no Query result bytes received. That run did not have main-entry instrumentation, so we cannot determine where its time was spent.

2. A later isolated, instrumented run measured:

   • posix_spawn return to Query main entry: 832.687 ms
   • main entry to return: 24.179 ms
   • Observer-measured Query elapsed time: 864 ms

3. Another isolated, instrumented run measured:

   • posix_spawn call duration: 0.179 ms
   • spawn return to main entry: 634.334 ms
   • main entry to return: 6.757 ms
   • Observer-measured Query elapsed time: 647 ms

In the third run, getrusage(RUSAGE_SELF) at main entry reported cumulative CPU time of 3.014 ms user and 2.583 ms system. Before main returned, the cumulative total was 8.088 ms. Timeline measurements used CLOCK_MONOTONIC.

Interpretation limits These successful diagnostic runs do not explain or resolve the historical timeout. Instrumentation changes the executable, and cache state and scheduling may differ.

The CPU and wall-clock measurements cover different intervals. Subtracting them would not give an exact waiting-time measurement. We cannot currently attribute the delay to dyld, scheduling, security checks, IPC, or I/O.

Diagnostic constraints We want to preserve the original parent-child relationship and avoid system-wide collection, disabling security protections, or silently changing permissions.

We have not established that the Instruments App Launch configuration available to us can capture this child’s earliest startup phases while restricting collection to Query.

The historical DYLD_PRINT_STATISTICS options are not documented in the installed dyld manual. Attaching a sampling tool after obtaining the PID may miss the relevant startup interval and may perturb this short-lived process.

Questions

1. What supported tool or API on this macOS version can distinguish startup phases before main() for this posix_spawn-created child?
2. Can collection itself be restricted to Query, rather than collecting system-wide data and filtering the report afterward?
3. What permissions are required, which early phases remain unobservable, and how much observer perturbation should we expect?
4. If these constraints cannot all be met, what is the smallest necessary change to the diagnostic setup?
5. What minimal sample project and evidence would be most useful for further investigation?

I have preserved the original failure and subsequent diagnostic evidence, but do not yet have a standalone Xcode sample that reliably reproduces the historical timeout.

I’m requesting guidance on an appropriate measurement method, not asserting that this is a confirmed macOS defect.