Also fixes gh-149507, regenerating `configure` for 3.16.
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Zachary Ware <zach@python.org>
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.
For Python macOS framework builds, update all Info.plist files to be more
compliant with current Apple guidelines. Original patch contributed by
Martinus Verburg.
Updated macOS framework Info.plist to use x.y.z format for CFBundleShortVersionString to comply with Apple guidelines. Patch contributed by Martinus Verburg.
The Tcl 9 makefile.vc now uses TCLSH_NATIVE during the build process,
not just the installation. We had been setting it to the installed
location of the x86 tclsh.exe, which does not yet exist when the x86
build process needs it. That build doesn't actually need TCLSH_NATIVE,
though (there's a check specifically allowing TCLSH to be used if
MACHINE is IX86 and TCLSH_NATIVE is undefined), so don't set it.
As part of this conversion, we now ensure that we're comparing against the
merge-base of the PR branch and the base branch when checking whether an RTD
build is worthwhile, deepening the history of the base branch by up to 500
commits if necessary. If the merge-base can't be found or there are merge
conflicts with the head of the base branch, the build is skipped since it would
give a warped perception of the actual changes anyway.
This unfortunately does nothing about RTD preview comments comparing against
the wrong base, other than skipping builds that shouldn't produce any diff at
all thus avoiding the comment.
Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) <wk.cvs.github@sydorenko.org.ua>
-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>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
* SEND specialization. Adds 2 new specialized instructions:
* SEND_VIRTUAL: for sends to virtual iterators e.g lists and tuples
* SEND_ASYNC_GEN: for sends to async generators
Tweak FOR_ITER_VIRTUAL so that SEND_VIRTUAL and FOR_ITER_VIRTUAL use equivalent guards
