Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3.13 can't compile with armv5 target #125444

Closed
rossburton opened this issue Oct 14, 2024 · 8 comments
Closed

Python 3.13 can't compile with armv5 target #125444

rossburton opened this issue Oct 14, 2024 · 8 comments
Assignees
Labels
3.13 bugs and security fixes build The build process and cross-build type-bug An unexpected behavior, bug, or error

Comments

@rossburton
Copy link
Contributor

rossburton commented Oct 14, 2024

Bug report

Bug description:

If we build cpython 3.13 for Linux/ARMv5 using -march=armv5te and then run inside a qemu with the versatilepb machine (which uses a ARM926EJ-S processor) then python crashes with "Illegal Instruction". Specifically, mrc is used in a few places to get the thread ID, but this not possible in cores lower than ARMv6K.

Users of mrc:

I suspect the best way of implemented the required check would be:

#if defined(__arm__) && __ARM_ARCH >= 6 && !defined(__ARM_ARCH_6__)

That is, if Arm and if the architecture level is 6 or great and if this is not bare v6 (so v6K/v6Z are included).

Or a blunter but simpler hammer on the grounds that v5/v6 is pretty niche these days could be:

#if defined(__arm__) && __ARM_ARCH >= 7

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

@rossburton rossburton added the type-bug An unexpected behavior, bug, or error label Oct 14, 2024
@rossburton
Copy link
Contributor Author

Paging @diegorusso.

@picnixz picnixz added the build The build process and cross-build label Oct 14, 2024
@diegorusso diegorusso self-assigned this Oct 14, 2024
@diegorusso diegorusso added the 3.13 bugs and security fixes label Oct 14, 2024
@diegorusso
Copy link
Contributor

On Arm v5 it is not possible to get the thread ID via register hence the illegal instruction. The c13 register started to provide thread ID since the rev1 (r1p0) release of the ARM1136JF-S processor which is an Arm v6K architecture varian. Other variants of Arm v6 (T2, Z and base ) don’t provide the thread ID via c13.
Said that, for the sake of simplicity here we could group v5 and v6 together and consider that instructions for v7 only (as @rossburton said).
This is also similarly done here: https://github.com/python/cpython/blob/main/Include/internal/mimalloc/mimalloc/atomic.h#L351

@colesbury
Copy link
Contributor

Does this affect the default build of Python 3.13 or just the free threading build? _Py_ThreadId() is only compiled in the free threading build.

Here's glibc's check, for what it's worth: https://github.com/bminor/glibc/blob/9d4b4515a88c5d0bbfc7809374f322c507c2d779/sysdeps/arm/sysdep.h#L59-L60

And their fallback:
https://github.com/bminor/glibc/blob/9d4b4515a88c5d0bbfc7809374f322c507c2d779/sysdeps/arm/sysdep.h#L265-L276

@kanavin
Copy link
Contributor

kanavin commented Oct 15, 2024

Does this affect the default build of Python 3.13 or just the free threading build? _Py_ThreadId() is only compiled in the free threading build.

We only test the default build, and indeed the issue in that build is seen only with the usage of the instruction in mimalloc. I've disabled mimalloc on armv5 as a workaround.

@diegorusso
Copy link
Contributor

diegorusso commented Oct 15, 2024

We are currently testing a patch that draws a line between Arm v6 and Arm v7. I guess we can go with a more precise grouping like glibc does but I feel it is not that necessary for a couple of reasons:

  • code maintenance: is it worth having different code paths compared with the number of use cases where an Arm v6K/v6ZK board needs to run Python with mimalloc/free threading? This differentiation will fade out in the coming years and by the time free threading will be enabled by default, the difference will be even more shallow.
  • testing: how are we going to have proper testing? Even now we are relying on software emulation to test it because it's already hard to fetch different variants of Arm v5/v6 boards.

glibc has that differentiation because it was introduce organically whilst being developed over the years (that differentiation was introduced 11 years ago and never changed it) and their main focus is back compatibility.
The backward compatibility that we have with mimalloc is not that deeper as the glibc one, and a division between Arm v6 and Arm v7 should suffice.

Anyway if anyone feels strong otherwise, we could push for a more precise grouping.

diegorusso added a commit to diegorusso/cpython that referenced this issue Oct 16, 2024
On Arm v5 it is not possible to get the thread ID via c13 register
hence the illegal instruction. The c13 register started to provide
thread ID since Arm v6K architecture variant. Other variants of
Arm v6 (T2, Z and base) don’t provide the thread ID via c13.
For the sake of simplicity we group v5 and v6 together and
consider that instructions for Arm v7 only.
diegorusso added a commit to diegorusso/cpython that referenced this issue Oct 16, 2024
On Arm v5 it is not possible to get the thread ID via c13 register
hence the illegal instruction. The c13 register started to provide
thread ID since Arm v6K architecture variant. Other variants of
Arm v6 (T2, Z and base) don’t provide the thread ID via c13.
For the sake of simplicity we group v5 and v6 together and
consider that instructions for Arm v7 only.
@diegorusso
Copy link
Contributor

diegorusso commented Oct 16, 2024

I have created the PR #125574, please have a look. Once we agree in an implementation, I will suggest the same fix to https://github.com/microsoft/mimalloc/ as well.

@rossburton
Copy link
Contributor Author

Looks good to me!

colesbury pushed a commit that referenced this issue Oct 16, 2024
On Arm v5 it is not possible to get the thread ID via c13 register
hence the illegal instruction. The c13 register started to provide
thread ID since Arm v6K architecture variant. Other variants of
Arm v6 (T2, Z and base) don’t provide the thread ID via c13.
For the sake of simplicity we group v5 and v6 together and
consider that instructions for Arm v7 only.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Oct 16, 2024
…ythonGH-125574)

On Arm v5 it is not possible to get the thread ID via c13 register
hence the illegal instruction. The c13 register started to provide
thread ID since Arm v6K architecture variant. Other variants of
Arm v6 (T2, Z and base) don’t provide the thread ID via c13.
For the sake of simplicity we group v5 and v6 together and
consider that instructions for Arm v7 only.
(cherry picked from commit feda9aa)

Co-authored-by: Diego Russo <[email protected]>
colesbury pushed a commit that referenced this issue Oct 16, 2024
…GH-125574) (GH-125595)

On Arm v5 it is not possible to get the thread ID via c13 register
hence the illegal instruction. The c13 register started to provide
thread ID since Arm v6K architecture variant. Other variants of
Arm v6 (T2, Z and base) don’t provide the thread ID via c13.
For the sake of simplicity we group v5 and v6 together and
consider that instructions for Arm v7 only.
(cherry picked from commit feda9aa)

Co-authored-by: Diego Russo <[email protected]>
@diegorusso
Copy link
Contributor

diegorusso commented Oct 16, 2024

Changes have been merged both on main and 3.13 branches.
I will port the fix to mimalloc in the coming days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes build The build process and cross-build type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

5 participants