While `pc` is not particularly wrong on x86_64, it's nonsensical on
other supported platforms, namely aarch64 and riscv64.
For consistency, we now don't use this vendor anymore, regardless of the
platform.
Within the LLVM project, we now build as `$arch-serenity`. This is
enough in most cases, the only place where we have to specify a vendor
is the target .cfg file where we use `$arch-unknown-serenity`.
When building GCC and friends, again we simply identify as
`$arch-serenity` and this is enough.
As a result, the tools in Toolchain/Local/$arch/bin are now named after
this pattern: `$arch-serenity-$tool`.
These changes affect the toolchain build scripts, serenity's build
scripts and the Ports.
The last place where we should see `x86_64-pc-serenity` is the output of
`config.sub`, which assume the vendor is `pc` on vendor-less `x86*`
triples. So `x86_64-serenity` is expanded to `x86_64-pc-serenity`,
luckily enough and AFAICT, the whole GNU ecosystem considers `pc`,
`unknown` and vendor-less target triples the same. So `configure`
shouldn't have an issue finding the right tools anyway.
The gn files were edited with sed and are not tested.
This commit also includes a check in `Meta/serenity.sh` to give a nicer
error message when trying to build the system with an old toolchain.
----
To test this patch, on a clean tree I:
- Ran `./Meta/serenity.sh x86_64 GNU`
- Ran `./Toolchain/BuildJakt.sh`
- Tested these ports: python3(configure based), libjxl(cmake based) and
rizin(meson based)
- Also booted on aarch64 and risv64
I also repeated the steps above with a Clang toolchain.
On a working tree I tested all the affected ports, the results are:
- tinycc build fine but can't compile programs, I observed the same on
master.
- gdb and epsilon don't build but report the same errors as on master.
- I manually edited the libgpg-error, and it builds fine.
- The gcc port works fine.
For some reason, this will become necessary in the next commit. This
library is already included in glibc so it is not needed to link against
it on Linux, but otherwise required.
This allows us to stop using MemoryType::IO for the DMA buffer.
MemoryType::NonCacheable is the default memory type parameter, so just
stop requesting MemoryType::IO explicitly.
These changes were upstreamed by timschumi a few years ago. The patch
was dropped by doing:
```
$ ./package.sh dev
$ git am --skip # As there are no changes on the git tree.
$ exit
```
Previously, we attempted to print the device creation error. But device
creation should have already succeeded to reach this if statement, so
we would always crash if hub creation failed (.error() panics if it's
not an error).
In environments without any `SERENITY*` variables, grep returns an exit
status of 1. This patch ensures that the subcommand exits with status 0
regardless of whether grep finds a match. This prevents the script
from bailing out when `set -eo pipefail` is enabled.
Previously, only AArch64 used its "pretty" architecture name.
This matches other operating systems. Our own host architecture
detection code also only accepts "aarch64" and "arm64", not "AArch64".
I think matching the uname machine strings of other operating systems is
better than changing the other machine strings to "x86-64" and
"RISC-V 64" or "RV64I" (for RISC-V there isn't really an official
architecture name for the 64-bit variant except "RV64I").
Before the previous commit, these tests would result in an infinite
loop.
These test cases use small enough fractions to avoid the bug from
GitHub issue #26640. The default precision is 6, so this should be
printed as "10" both with correct and incorrect %g precision behavior.
Previously, small fractions that round to zero when converting them to
an integer would cause an infinite loop, since `ifraction % 10` is
always zero in that case.
When `ifraction` is zero, we don't need to print a fraction, so just
skip printing it.
These two lines seem unnecessary to boot on x86_64, aarch64 and riscv64.
It's not obvious to me why they were added in the first place (it was
in this commit: b5c98ede08).
The idea is described here https://kornel.ski/deringing/. And allows
reducing the noise around sharp white edges. This is visible when
encoding an image like `buggie.png`. One nice aspect of the optimization
is that it only affects macroblocks where it can help.
Instead of defining LITTLE_ENDIAN and BIG_ENDIAN ourselves, we should
use the definitions from the compiler.
Additionally, we don't have <bits/endian.h>, so it's never correct to
include that header.
These definitions appear to be unused and are not required by POSIX.
They appear to be specific to OpenBSD and do not seem to exist on any
other system.
We don't check for feature test macros in any other LibC header, and
especially not for _GNU_SOURCE or _BSD_SOURCE. With no feature test
macro defined, this header would previously essentially be empty.
POSIX doesn't seem to require any feature test macros for this header
either.
This was motivated by Clang removing `__builtin_ia32_sqrtps` for the
22.1.0 release:
https://github.com/llvm/llvm-project/pull/165682
This should also allow vectorized square root on non-x86 systems when
using Clang.
059f280eb9 forgot to add a final newline character, causing all
addresses to be printed in one line.
Additionally, early kernel addresses were previously not printed in a
kernel load address-relative format like we do for non-early backtraces.
Lucas Chollet