config.sub was mapping all single-component shorthands matching the
shell glob `dpx2*` to ‘m68k-bull-sysv3’, which is incorrect. Of the
four different machines once manufactured by Groupe Bull whose model
number can be abbreviated ‘dpx2something’, only two were m68k-based:
the DPX/2-200 and DPX/2-300. The DPX/2-100, on the other hand, had an
i386 CPU. And the DPX/20 was a completely different beast, released
years later and based on the POWER architecture.
I’ve chosen to keep making ‘dpx2’ map to ‘m68k-bull-sysv3’ as the
DPX/2-200 and /2-300 seem to have been the most widely used. config.sub
now understands ‘dpx2100’, ‘dpx2200’, and ‘dpx2300’ as shorthands for
‘i386-bull-sysv3’, ‘m68k-bull-sysv3’, and ‘m68k-bull-sysv3’ respectively.
It also accepts ‘dpx21xx’, ‘dpx22xx’, and ‘dpx22xx’ as equivalent to
these, but no other variations; in particular, ‘dpx2xxx’, which was in
the test suite, no longer works, as it is ambiguous.
(As far as I can tell, there weren’t actually any submodels of any of
these systems, so I could be persuaded to remove the …xx aliases.
I kept them mainly because of the test suite formerly testing dpx2xxx.)
Finally ‘dpx20’ now maps to ‘rs6000-bull-bosx’. Both the ‘rs6000’ and
‘bosx’ components of this name are debatable, but I *think* it is what
config.guess would do on this machine.
Sources for Bull DPX/2whatever history:
- https://oldskool.silicium.org/stations/bull_dpx20.htm
- https://www.feb-patrimoine.com/english/bull_dpx2.htm
- https://www.feb-patrimoine.com/english/unix_and_bull.htm
Note in particular “Que cette machine soit estampillée BULL ou IBM,
elle faisait tourner AIX (l'Unix d'IBM)” on the first of these pages,
which is why I say “bosx” is debatable…
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Add support for [OpenHarmony] targets.
The `ohos` targets are available [in `LLVM`] and
documented in the [Rust target documentation].
Known targets in Rust:
- aarch64-unknown-linux-ohos
- armv7-unknown-linux-ohos
- x86_64-unknown-linux-ohos
Known targets in Clang:
- arm-linux-ohos
- aarch64-linux-ohos
- x86_64-linux-ohos
There are also some additional targets available in clang,
e.g. `liteos-ohos`, but I don't know much about those
targets, so I'm leaving `liteos-ohos` out of scope for this
patch.
[OpenHarmony]: https://gitee.com/openharmony/docs/
[in `LLVM`]: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/OHOS.cpp
[Rust target documentation]: https://doc.rust-lang.org/rustc/platform-support/openharmony.html
* config.sub ($os == ohos*): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (aarch64-linux-ohos): New entry.
Signed-off-by: Jonathan Schwender <jonathan.schwender@huawei.com>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
ARM64E is a custom ABI for AArch64 8.3+ introducing pointer
authentication codes. While technically just an ABI, it is treated
as its own machine type, with triples in the format arm64e-*.
* config.sub (arm64e): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm64e-apple-darwin20.0.0,
arm64e-apple-ios): New entries.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
`windows-gnu` has been used by LLVM and Rust to mean MinGW, but many
people on the mailing list object that it is in no way bona fide GNU on
Windows. Even under the interpretation of `-gnu` as a libc which LLVM
often goes with, it doesn't pass muster either because MinGW uses
msvcrt/ucrt, not any GNU libc. Arguably Cygwin, using a modified (GNU)
Newlib, is the closest thing we have to "GNU on Windows" today.
We couldn't decide on what `windows-*` should replace it, or even
whether there should be such a thing, so absent consensus it is better
to just remove it while it is still recently added and we don't need to
worry about backwards compatibility. We can always re-add it later, but
we can't do nothing now and remove it later.
This partially reverts commit 91f6a7f616b161c25ba2001861a40e662e18c4ad.
* config.sub (windows*-gnu*): Remove.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (x86_64-windows-gnu): Remove.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
ARM64EC is a custom ABI for AArch64 that allows for interoperability
with x86_64 compiled code. While technically just an ABI, it is treated
as its own machine type, with triples in the format arm64ec-*.
* config.sub (arm64ec): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm64ec-pc-mingw32, arm64ec-windows): New
entries.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
config.guess says aarch64c-unknown-freebsd14.0 (cfarm240.cfarm.net,
an Arm Morello SoC, quad-core aarch64 Neoverse N1-based CPU
implementing CHERI), so let config.sub allow it.
* config.sub (aarch64c): Recognize.
* doc/config.sub.1: Regenerate.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
GHC has been using a custom triple "javascript-unknown-ghcjs" for
their (non asm.js, non wasm) javascript-emitting kernel-less target.
This triple is a bit of an oddball, so the support for it is highly
restricted in order to discourage further proliferation of the
javascript "cpu" or ghcjs "operating system", which are valid only
in combination with each other.
* config.sub (javascript-*-ghcjs): Allow.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (javascript-ghcjs,
javascript-unknown-ghcjs): New entries.
Link: 6636b67023
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Instead of treating them as OSes, we treat them as their own category.
This is modeled on what LLVM does with its `ObjectFormatType` enum [1],
advancing my long-running project of trying to nudge GNU config and LLVM
towards each other, taking the best ideas of both.
Currently, my emphasis is just on code cleanup. There are just a few
tests for newly supported changes that fall out of this. But down the
road, this also opens the door to parsing configs with more than 4
components, like [2].
[1]: https://llvm.org/doxygen/classllvm_1_1Triple.html#a83e907e55fa50e093caa96a0aff96201
[2]: a18266473b/llvm/unittests/TargetParser/TripleTest.cpp (L1873C50-L1873C77)
added in
28b82bc39e
* config.sub: Save machine code format name separately from the OS name.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (arm-unknown-none-aout,
arm-unknown-none-pe): New entries.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
GNU binutils support the selection of the default MIPS subtarget via the
configuration triplet, e.g. `mips64octeon+el-unknown-linux-gnu' builds a
Linux/GNU 64-bit MIPS (n32 ABI) little-endian configuration with the CPU
set to Octeon+ by default. However `config.sub' rejects such a triplet
and indeed it only lets through a random choice of ones people submitted
changes for to support.
There is a large number of MIPS CPU configurations, 118 at the moment,
that GNU binutils know, so rather than adding them individually and then
hoping it will be kept up to date from now on accept any `mips*' pattern
for the machine part, just as we already do for a few of other targets.
* config.sub: Allow any `mips*' CPU rather than listing a choice
individually.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data: Add test cases.
These are distinct from "ios". They are also technically Darwin, so while
something like "aarch64-apple-darwin" could be used when targeting these,
on Apple-silicon based systems there could be cases where `--host` and
`--build` have the same value, and a ./configure script may determine that
we are not cross building, causing it to try to execute test programs for
the target OS that will not run on macOS.
These are functionally equivalent to iOS, and targets with "-tvos" and
"-watchos" are already used by clang.
* config.sub (tvos*, watchos*): Recognize.
* testsuite/config-sub.data (arm64-apple-tvos, arm64-apple-tvos10.0.0,
arm64-apple-watchos, arm64-apple-watchos5.0): New tests.
* doc/config.sub.1: Regenerate.
These are not real OSes, they are object file formats. There is a
longstanding tradition of using them for embedded/freestanding
programming, so it makes sense to parse them with `kernel=none`.
(I have a WIP future patch that systematizes parsing these non-OSes a
bit more. That also opens the door to parsing a 5th component as LLVM
can do.)
This change unblocks an issue we've been having with Nixpkgs (see
https://github.com/NixOS/nixpkgs/issues/165836 for the longer version).
* config.sub (none-coff*, none-elf*): Recognize.
* testsuite/config-sub.data (arm-unknown-none-coff,
arm-unknown-none-elf, riscv64-company-none-elf): New tests.
* doc/config.sub.1: Regenerate.
In older times, MinGW (GCC toolchain with modified windows headers) was
the only free software toolchain for Windows. But now, LLVM has support
both for MinGW ABI and Microsoft's own. The distinction matters for C++
more than C.
LLVM[1], Rust[2], and other projects have taken to differentiating these
two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
of sense, as it correctly identifiers both their commonalities and their
differences.
A lot of MinGW-supporting software, most notably GCC itself, will
presumably continue to use configs like x86_64-pc-mingw32 and
i686-pc-mingw32. That's fine; this patch doesn't normalize them away
(like LLVM does) or remove them! If and when that software wants to
support the MSVC ABI without requiring MSVC itself, they can switch to
these newer configurations.
[1]: a18266473b/llvm/unittests/TargetParser/TripleTest.cpp (L1907-L1951)
[2]: 36fb58e433/compiler/rustc_target/src/spec/mod.rs (L1255-L1271)
In 2012 the GNU Coding Standards changed to recommend quoting
'like this' or "like this" instead of `like this'.
Alter diagnostics and comments accordingly.
Use a more-consistent quoting style in config.sub diagnostics,
preferring 'like this' to "like this" as the former is more
resistant to shell metacharacters.
See: https://www.gnu.org/licenses/gpl-3.0.html#howto
Update license headers automatically using the following script:
$ git grep -l 'Foundation; either version 3' \
| xargs sed -i '/Foundation; either version 3/ s/n; e/n, e/'
* config.guess: Adjust via the above command.
(timestamp): Update.
* config.sub: Likewise.
* doc/config.guess.1: Regenerate.
* doc/config.sub.1: Likewise.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
ALT uses armh as an alias for armv7l-alt-linux-gnueabihf since 2012.
* config.sub (armh-unknown|armh-alt): Set cpu, vendor, and basic_os.
(timestamp): Update.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data (armh, armh-alt-linux-gnueabihf): New tests.
When combining variable assignments with a shell command, some older
shells (notably heirloom-sh and presumably also Solaris 10 /bin/sh)
have a bug which causes the assignment to alter the current execution
environment whenever the command is a shell built-in. For example:
% dash -c 'x=good; x=bad echo >/dev/null; echo $x'
good
% jsh -c 'x=good; x=bad echo >/dev/null; echo $x'
bad
The config.sub script contains a few commands of the form:
IFS=- read ...
which triggers this bug, causing the IFS assignment to persist for the
remainder of the script. This can cause misbehaviour in certain cases,
for example:
% jsh config.sub i386-linux-gnu
config.sub: test: unknown operator gnu
% jsh config.sub i386-gnu/linux
sed: can't read s|gnu/linux|gnu|: No such file or directory
Invalid configuration `i386-gnu/linux': OS `' not recognized
* config.sub: Save and restore IFS explicitly to avoid shell bugs.
* doc/config.sub.1: Regenerate.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Some cases quote the argument to echo and some do not. At runtime
it probably does not matter because the substituted values will never
contain whitespace, but quoting them all would make shellcheck more
useful.
* config.sub: Consistently quote the argument of echo.
* doc/config.sub.1: Regenerate.
Suggested-by: Jacob Bachmeyer <jcb@gnu.org>
Signed-off-by: Ozkan Sezer <sezero@users.sourceforge.net>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Complement binutils commit ae52f4830604 ("Add MIPS r3 and r5 support.")
and recognize MIPS CPU patterns for the R3 and R5 ISA levels, used by
GAS to set defaults.
* config.sub (mipsisa32r3, mipsisa32r3el, mipsisa32r5, mipsisa32r5el,
mipsisa64r3, mipsisa64r3el, mipsisa64r5, mipsisa64r5el): Recognize.
* doc/config.sub.1: Regenerate.
* testsuite/config-sub.data: Add test cases.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Recently RISC-V community got patches big-endian support for binutils,
and we'd like to accept that, however before accepting that I think it
would be better to upstream config.sub and config.guess change here :)
It's my check result on Ubuntu 18.04:
$ make check
cd testsuite && bash config-guess.sh && rm uname
PASS: config.guess checks (131 tests)
cd testsuite && bash config-sub.sh
PASS: config.sub checks (830 tests)
PASS: config.sub idempotency checks (767 tests)
PASS: config.sub canonicalise each config.guess testcase (131 tests)
* config.guess (riscv32be:Linux:*:*, riscv64be:Linux:*:*): Recognize.
* config.sub (riscv32be, riscv64be): Likewise.
* doc/config.guess.1: Regenerate.
* doc/config.sub.1: Likewise.
* testsuite/config-guess.data: Add test cases for riscv32be, and riscv64be.
* testsuite/config-sub.data (riscv32be, riscv64be): Add test cases.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
