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.

Sign up for GitHub

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

Jump to bottom

Inconsistent host_machine.cpu() for Debian ppc64el cross vs. native #13741

Open
smcv opened this issue Oct 2, 2024 · 1 comment
Open

Inconsistent host_machine.cpu() for Debian ppc64el cross vs. native #13741

smcv opened this issue Oct 2, 2024 · 1 comment

Comments

@smcv
Copy link
Contributor

smcv commented Oct 2, 2024

Describe the bug
On Debian ppc64el (64-bit PowerPC little-endian), Meson detects the host_machine.cpu() to be ppc64le during native builds, but meson env2mfile says ppc64el instead.

Which of these should it ideally be?

  1. ppc64, matching the cpu_family() and disregarding the endianness;
  2. ppc64le, matching a typical Linux uname -m output on these machines;
  3. ppc64el, matching the Debian architecture name (probably not this one)

For completeness, GNU tools call this architecture powerpc64le-linux-gnu.

To Reproduce
For a native build: https://buildd.debian.org/status/package.php?p=libglvnd is a convenient example of a package that logs the cpu() and cpu_family() during meson setup.

For a cross-build: source code inspection, or run the unit test that I'm going to propose as a PR, or install ppc64el cross-compilers and run meson env2mfile (a precise reproducer is left as an exercise to the reader).

Expected behavior
If I do a native build and a cross-build, both with ppc64el as the host architecture, they should agree on the name of the CPU.

system parameters

  • Is this a cross build? yes and no, see above
  • what operating system? Debian unstable
  • what Python version are you using? 3.12.6
  • what meson --version? 1.5.2 or git master
  • what ninja --version? irrelevant
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
ceab9db 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Signed-off-by: Simon McVittie <[email protected]>
@smcv smcv mentioned this issue Oct 2, 2024
Merged
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
cdbe731 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Signed-off-by: Simon McVittie <[email protected]>
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
2601cff 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Signed-off-by: Simon McVittie <[email protected]>
@smcv smcv changed the title Inconsistent host_machine.cpu() for Debian ppc64el Inconsistent host_machine.cpu() for Debian ppc64el cross vs. native Oct 2, 2024
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
f9f6b2b 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Resolves: mesonbuild#13742
Signed-off-by: Simon McVittie <[email protected]>
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
fc87950 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Resolves: mesonbuild#13742
Signed-off-by: Simon McVittie <[email protected]>
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
7dd17f3 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Resolves: mesonbuild#13742
Signed-off-by: Simon McVittie <[email protected]>
smcv added a commit to smcv/meson that referenced this issue Oct 2, 2024
@smcv
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
3614f58 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see mesonbuild#13741 for that.

Resolves: mesonbuild#13742
Signed-off-by: Simon McVittie <[email protected]>
@smcv
Copy link
Contributor Author

smcv commented Oct 2, 2024 •
edited
Loading

For native builds and the build architecture, detect_cpu_family() has a special case that normalizes powerpc64* and ppc64* to ppc64, but detect_cpu() does not have a matching special case, resulting in this inconsistency.

For cross-builds, env2mfile seems to be trying to map powerpc64le to ppc64 in its lookup tables for both cpu_family() and cpu(), but this is ineffective, because the key that is used for the lookup for cpu() is a Debian architecture name (amd64, ppc64el) and not a GNU CPU name (x86_64, powerpc64le). For amd64, this is fixed by #13722, which has the side-effect of changing the cpu() for ppc64el to ppc64, matching the cpu_family().

The downstream debcrossgen tool written by @jpakkane is currently used in Debian for cross-compiling (with the goal of having meson env2mfile replace it), and it similarly appears to be trying to map powerpc64le to ppc64, but similarly this is ineffective because powerpc64le is not the key that is looked up.

I think this maybe means that ppc64 would be the correct answer?

jpakkane pushed a commit that referenced this issue Oct 2, 2024
@smcv @jpakkane
env2mfile: Base cpu on DEB_HOST_GNU_CPU unless DEB_HOST_ARCH is special
9d0de83 
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.

However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).

When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.

When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see #13741 for that.

Resolves: #13742
Signed-off-by: Simon McVittie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@smcv