--with-*address-sanitizer and --with-memory-sanitizer unconditionally
disabled pymalloc (even when --with-pymalloc was given explicitly).
Enable it, so that it's available with `PYTHONMALLOC=pymalloc`.
Disable it by default on the affected sanitizer builds.
* Run the test suite with MSan in CI
* Additional fixes
* Add `_Py_MSAN_UNPOISON_STRING`
* Apply Victor's suggestions
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
* Apply Victor's suggestions
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
---------
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
Allows a static build of iOS for users that want to build and embed a libPython
into an iOS binary. This configuration can't use shared modules or binary
wheels, but it can be useful under some circumstances, so there's no reason to
explicitly exclude it.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Expand the documentation for the -x command-line option to explain its
purpose and usage for turning Python scripts into Windows batch files,
with examples of batch file header lines.
Co-authored-by: Rory Glenn <glennrory@gmail.com>
Co-authored-by: Brian Schubert <brianm.schubert@gmail.com>
Add --with-curses=ncursesw|ncurses|curses|no, mirroring --with-readline.
The default (auto) keeps the current behaviour: prefer ncursesw, fall back
to ncurses. --with-curses=curses links the system's native curses (e.g. on
NetBSD or Solaris), which has no pkg-config file and was previously
unreachable; it is built with wide-character support when the library
provides it. --without-curses excludes the curses and _curses_panel modules
from the build.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Configurable build-details.json name
Linux distributions that co-install multiple Python versions in the same
path (e.g. multiarch on Debian, debug builds, and free-threading) need a
way to place multiple build-details.jsons side-by-side.
PEP-739 is being updated [0] to recommend renaming in this situation. To
ensure some standardization, this PR generates appropriate names for
distributions that need to use this feature.
[0]: https://github.com/python/peps/pull/4889
* NEWS entry
* Document configure option and add to whatsnew
The power ABI specification requires that compilers maintain a back
chain by default, so unwinding already works without a dedicated
frame pointer. Don't use -fno-omit-frame-pointer on ppc64le.
-fno-omit-frame-pointer is not enough to make every target walkable by the
simple manual frame pointer unwinder.
The helper used by test_frame_pointer_unwind used to assume the frame pointer
named a two-word record where fp[0] was the previous frame pointer and fp[1]
was the return address. That is only the generic layout used by some targets.
This patch keeps that default, but moves the slots behind named offsets so
architecture-specific layouts can describe where the backchain and return
address really live.
On s390x, GCC and Clang do not emit a usable backchain unless -mbackchain is
enabled. Without it, the unwinder stops at the current C frame and the test
reports no Python frames. Once backchains are present, the helper must also
stop at the current thread's known C stack bounds; otherwise it can follow the
final backchain far enough to dereference an invalid frame and segfault.
For Linux s390x backchain frames, the documented z/Architecture stack-frame
layout saves r14, the return-address register, at byte offset 112 from the
frame pointer, so read the return address from that named slot instead of fp[1].
The 112-byte offset comes from Linux's s390 debugging documentation: its Stack
Frame Layout table shows z/Architecture backchain frames with the backchain at
offset 0 and saved r14 of the caller function at offset 112:
https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#stack-frame-layout
This helper remains scoped to Linux s390x backchain frames. GNU SFrame's s390x
notes state that the s390x ELF ABI does not generally mandate where RA and FP
are saved, or whether they are saved at all:
https://sourceware.org/binutils/docs/sframe-spec.html#s390x
As Jens Remus noted, -fno-omit-frame-pointer is not needed when -mbackchain is
present.
On 32-bit ARM, GCC defaults to Thumb mode on common armhf toolchains. The Thumb
prologue keeps the saved frame pointer and link register at offsets that depend
on the generated frame, which breaks the fp[0]/fp[1] walk used by the helper.
Use -marm when it is supported for frame-pointer builds, and teach the helper
the GCC ARM-mode slots where the previous frame pointer is at fp[-1] and the
saved LR return address is at fp[0].
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
This option changes the behavior of --enable-shared to continue to build
the libpython3.x.so shared library, but not use it for linking the
python3 interpreter executable. Instead, the executable is linked
directly against the libpython .o files as it would be with
--disable-shared.
There are two benefits of this change. First, libpython uses
thread-local storage, which is noticeably slower when used in a loaded
module instead of in the main program, because the main program can take
advantage of constant offsets from the thread state pointer but loaded
modules have to dynamically call a function __tls_get_addr() to
potentially allocate their thread-local storage area. (There is another
thread-local storage model for dynamic libraries which mitigates most of
this performance hit, but it comes at the cost of preventing
dlopen("libpython3.x.so"), which is a use case we want to preserve.)
Second, this improves the user experience around relocatable Python a
little bit, in that we don't need to use an $ORIGIN-relative path to
locate libpython3.x.so, which has some mild benefits around musl (which
does not support $ORIGIN-relative DT_NEEDED, only $ORIGIN-relative
DT_RPATH/DT_RUNPATH), users who want to make the interpreter setuid or
setcap (which prevents processing $ORIGIN), etc.
Davi de Jesus