feat(prof): use a trampoline for FLF functions to intercept timings

[bwoebi]

Frameless functions (FLF) do not check the EG(vm_interrupt) flag like it would happen usually on internal function returns. This means that from the point of view of the profiler, those functions do not exist, as the engine never checks the interrupt flag and as such never calls the profilers interrupt handler.

This PR adds a trampoline for aarch64 and x84_64 to all known frameless functions and a tail call to check the EG(vm_interrupt) flag and in case it is raised, call the interrupt handler.

One (acceptable) trade-off is that using these trampolines, libunwind in the crash tracker is not able to unwind passed the trampoline. Anyway, the impact is minimal:

• Stack frames from the crash site up to the trampoline are still captured
• Only frames above the trampoline (from caller to main) are lost
• For most crashes, the relevant context is near the crash site, not at the program entry point

The profiler itself is unaffected of this, as we are unwinding the VM stack, following the execute_data linked list.

https://datadoghq.atlassian.net/browse/PROF-12085

[datadog-datadog-prod-us1]

⚠️ Tests

✨ Fix all issues with Cursor

⚠️ Warnings

🧪 1026 Tests failed

    testSearchPhpBinaries from integration.DDTrace\Tests\Integration\PHPInstallerTest (Fix with Cursor)

testSimplePushAndProcess from laravel-58-test.DDTrace\Tests\Integrations\Laravel\V5_8\QueueTest (Datadog) (Fix with Cursor)

Risky Test
phpvfscomposer://tests/vendor/phpunit/phpunit/phpunit:60

testSimplePushAndProcess from laravel-8x-test.DDTrace\Tests\Integrations\Laravel\V8_x\QueueTest (Datadog) (Fix with Cursor)

DDTrace\Tests\Integrations\Laravel\V8_x\QueueTest::testSimplePushAndProcess
Test code or tested code printed unexpected output: spanLinksTraceId: 699350ef00000000f0161d2ef392ff64
tid: 699350ef00000000
hexProcessTraceId: f0161d2ef392ff64
hexProcessSpanId: 8ac716aa24c57361
processTraceId: 17300047106082537316
processSpanId: 9999986417616647009

View all

ℹ️ Info

❄️ No new flaky tests detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0dd28b4 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.11%. Comparing base (72a021a) to head (0dd28b4).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3595      +/-   ##
==========================================
- Coverage   62.21%   62.11%   -0.11%     
==========================================
  Files         141      141              
  Lines       13387    13387              
  Branches     1753     1753              
==========================================
- Hits         8329     8315      -14     
- Misses       4260     4273      +13     
- Partials      798      799       +1     

see 3 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 72a021a...0dd28b4. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[morrisonlevi]

I assume this can run afoul of permissions somehow, since we're making executable code at runtime? I'm not well versed here, and yes, if the JIT is enabled you'd have to have that capability anyway, but I'm trying to understand implications of this WIP.

[pr-commenter]

Benchmarks [ profiler ]

Benchmark execution time: 2026-02-16 17:25:03

Comparing candidate commit 0dd28b4 in PR branch bob/prof-flf-test with baseline commit 72a021a in branch master.

Found 0 performance improvements and 3 performance regressions! Performance is the same for 26 metrics, 7 unstable metrics.

scenario:php-profiler-timeline-memory-control

• 🟥 cpu_user_time [+31.545ms; +40.104ms] or [+5.189%; +6.597%]
• 🟥 execution_time [+30.889ms; +34.650ms] or [+4.847%; +5.437%]

scenario:php-profiler-timeline-memory-with-profiler

• 🟥 execution_time [+27.285ms; +40.639ms] or [+2.712%; +4.040%]

[bwoebi]

@morrisonlevi dynasmrt takes care of setting RX permissions after compiling the code. As long as you're not running this under a hardened runtime (like app store apps or android (?)), there's no fundamental problem. Also I currently call assembler.finalize().unwrap() (which takes care of settign RX) - proper usage should just handle the potential error here and abort.

[cataphract]

I assume original is not returning anything, because you're writing over RAX.

[bwoebi]

Correct

[cataphract]

this overwrites x30/lr, aren't you gonna lose the original return location of the handler? so when br x16 returns, it goes back to calling interrupt_addr

[bwoebi]

Ah, right. call on x86_64 pushes %eip to the stack, but blr doesn't.

[bwoebi]

Fixed up, is it correct now?

[realFlowControl]

Thanks @bwoebi this is awesome!