You can use preprocesor macros if you name the fileObjects/asm_trampoline.S or.sx instead ofObjects/asm_trampoline.s. The.sx form needs a makefile rule.

You can use preprocesor macros if you name the fileObjects/asm_trampoline.S or.sx instead ofObjects/asm_trampoline.s. The.sx form needs a makefile rule.

Hummm, not sure I follow, could you maybe show me an example of what we can achieve with this?

You can have multiple implementations in the same file:

    .text    .globl_Py_trampoline_func_start_Py_trampoline_func_start:#ifdef __x86_64__    push   %rbp    mov    %rsp,%rbp    mov    %rdi,%rax    mov    %rsi,%rdi    mov    %rdx,%rsi    mov    %ecx,%edx    call   *%rax    pop    %rbp    ret#endif // __x86_64__#ifdef __aarch64__    TODO#endif    .globl_Py_trampoline_func_end_Py_trampoline_func_end:

Why did you add a Windows build file? How about we do not define_PyPerfTrampoline_Init unless HAVE_PERF_TRAMPOLINE is defined?

Why did you add a Windows build file? How about we do not define_PyPerfTrampoline_Init unless HAVE_PERF_TRAMPOLINE is defined?

Then we need to add more ifdef every place is used but that works as well for sure

Two thoughts have been running around in my mind:

(1) We've got the command line flag and sys API, but what about just enabling this system wide or at least task/job wide within a container? An environment variable that turns it on would make that easy without plumbing options through.PYTHONPERFSUPPORT=1 as another equivalent to-Xperf? That's usually done in initconfig.c alongside the -X processing I believe.

Second: multiprocessing spawn start method. If the-Xperf flag was passed to the parent process I assume the "spawn" method should also pass that to its children.

I think (1) makes sense and is indeed coherent with how we handle some of the other options liketracemalloc so I will add an environment variable alongside the -X option.

Regarding (2) I am not that sure. We don't do this for the rest of the flags that we pass around and you can achieve the same with the environment variable if you want. In any case, as that would require some tests I would prefer to do that in a separate PR as this is already gigantic

I implemented the environment variable and solved a bunch of conflicts. Please check it out when you have time.

I also had to solve a bunch of conflicts.@gpshead if you are ok with the current status I would like us to land if everything looks good as the size of the PR is already attracting a bunch of merge conflicts in the build system, clinic and other files.

Ah wait, I need to document the environment variable. Will push a commit for that soon.

Ah wait, I need to document the environment variable. Will push a commit for that soon.

Done 👍

@erlend-aasland has mentioned that he was a bunch of docs improvements that he will do in a separate PR.

Damn,@miss-islington has landed the PR without waiting for the CI to build the last commit I pushed so I created#96433.

Thanks, everyone for the fantastic reviews and for helping to get this feature ready ❤️

You all rock 🤘

@erlend-aasland You can make the doc improvement PR after#96433 lands.

Thanks for all for pushing for better interoperability withperf(1). I highly appreciate this contribution. 🙏

Nice feature!

There is a typo in sys.deactivate_stack_trampoline() docstring: "Dectivate the perf profiler trampoline": Deactivate.

In the doc,python -m sysconfig | grep HAVE_PERF_TRAMPOLINE can be replaced withpython -c "import sysconfig; print(bool(sysconfig.get_config_var('PY_HAVE_PERF_TRAMPOLINE')))" to not rely on the externalgrep command. At least, I suggest to add PY_ to fix the variable name:

python -m sysconfig | grep PY_HAVE_PERF_TRAMPOLINE

The second command can be replaced withpython -c "import sysconfig; print('no-omit-frame-pointer' in sysconfig.get_config_var('PY_CORE_CFLAGS'))".

There is a typo in sys.deactivate_stack_trampoline() docstring: "Dectivate the perf profiler trampoline": Deactivate.

[...]

See#96445 :)

@pablogsal

Is it possible to port these changes, from python 3.12, without breaking to previous python versions, say 3.11, 3.10, 3.9?

Why?
Some libraries use specific versions of python and it will take time until they catch up to 3.12's release. This will defer the insights that can be gained till later on.

Is it possible to port these changes, from python 3.12, without breaking to previous python versions, say 3.11, 3.10, 3.9?

Is possible, but as these versions are only accepting security fixes or bugfixes we cannot backport new features. This means that if you want you can backport them yourself but you need to maintain a fork of the interpreter.