Re: [PATCH v2 00/20] aarch64-gnu port & GNU/Hurd on AArch64 progress

Hello, Sergey Bugaev, le sam. 23 mars 2024 20:32:41 +0300, a ecrit: > This is v2 of my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit > ARM. v1 is here [0]. Thanks! I applied the easy parts: patches 1-6 and 18 for now. Samuel

[PATCH v2 12/20] mach: Declare the new thread_set_self_state () trap

This is a new Mach trap for setting the state of the current thread, as if with thread_set_state () RPC. The trap has been added to GNU Mach as a part of the AArch64 port, to make it possible to implement sigreturn in glibc; however, the trap itself is fully arch-independent. There does not seem

[PATCH v2 10/20] aarch64: Allow building without kernel support for BTI

If PROT_BTI is not defined, turn _dl_bti_protect () into a no-op. We intend to support BTI & PROT_BTI on the Hurd eventually, but we're not there yet. Signed-off-by: Sergey Bugaev --- sysdeps/aarch64/dl-bti.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/sysdeps/aarch64/dl-bti

[PATCH v2 15/20] hurd: Implement longjmp for AArch64

This is based on the generic AArch64 version, but it additionally respects and updates the Hurd sigstate. Signed-off-by: Sergey Bugaev --- Same patch as last time. Something somewhere here should probably be hooked up to the hurd_userlink mechanism; I haven't looked into that. sysdeps/aarch64

[PATCH v2 17/20] hurd: Add an AArch64 signal implementation

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/aarch64/Makefile | 4 + sysdeps/mach/hurd/aarch64/bits/sigcontext.h | 96 ++ sysdeps/mach/hurd/aarch64/exc2signal.c | 149 + sysdeps/mach/hurd/aarch64/intr-msg.h| 123 sysdeps/mach/hurd/aarch64/sigret

[PATCH v2 04/20] hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now

While we could support it on any architecture, the tunable is currently only defined on x86_64. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/dl-sysdep.c | 2 +- sysdeps/mach/hurd/mmap.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sysdeps/mach/hurd/dl-sysdep.

[PATCH v2 13/20] hurd: Add a basic AArch64 port

The following commits will add TLS, HTL, and the signal bits. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/aarch64/Implies| 3 ++ sysdeps/mach/hurd/aarch64/longjmp-ts.c | 49 ++ sysdeps/mach/hurd/aarch64/shlib-versions | 2 + sysdeps/mach/hurd/aarch64/static

[PATCH v2 18/20] htl: Implement some support for TLS_DTV_AT_TP

Signed-off-by: Sergey Bugaev --- htl/pt-create.c | 2 ++ sysdeps/htl/dl-thread_gscope_wait.c | 16 ++-- sysdeps/mach/hurd/htl/pt-sysdep.c | 9 + 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/htl/pt-create.c b/htl/pt-create.c index fac6

[PATCH v2 08/20] aarch64: Add dl-procinfo

This is based on the Linux version, but doesn't define GLRO(dl_aarch64_cap_flags) and implement _dl_hwcap_string (which seems unused anyway) based on Linux HWCAP bit values. Signed-off-by: Sergey Bugaev --- sysdeps/aarch64/dl-procinfo.c | 59 +++ sysdeps/aarch64/d

[PATCH v2 11/20] mach: Add a basic AArch64 port

This doesn't add any of the Hurd- or HTL-specific bits yet. Signed-off-by: Sergey Bugaev --- mach/Makefile | 1 + sysdeps/mach/aarch64/bits/mach/param.h | 24 ++ sysdeps/mach/aarch64/cpu-features.c| 109 + sysdeps/mach/aarch64/sys/ucont

[PATCH v2 16/20] Add FPE_FLTIDO

This is a new si_code value for the SIGFPE signal that has been added to FreeBSD, and is also going to be used on the Hurd. Signed-off-by: Sergey Bugaev --- This makes sense, right? We should probably define more codes still (see exception2signal in the next patch). bits/siginfo-consts.h | 4

[PATCH v2 19/20] htl: Add an AArch64 implementation

Signed-off-by: Sergey Bugaev --- sysdeps/aarch64/htl/Makefile | 20 ++ sysdeps/aarch64/htl/bits/pthreadtypes-arch.h | 36 ++ sysdeps/aarch64/htl/machine-sp.h | 29 sysdeps/aarch64/htl/pt-machdep.h | 28 sysdeps/mach/hurd/aarch6

[PATCH v2 09/20] aarch64: Move saving user entry into _dl_start_user

In the Hurd ports, _dl_start () does not return the normal way; instead, _dl_sysdep_start () jumps to _dl_start_user directly using the RETURN_TO macro. Unlike in the i386 and x86_64 ports, the instruction that was saving the returned user entry into a different register (to avoid it getting clobb

[PATCH v2 20/20] hurd: Add expected aarch64-gnu abistlists

Signed-off-by: Sergey Bugaev --- We obviously didn't make it into the 2.39 timeframe, so now tentatively targeting 2.40. sysdeps/mach/hurd/aarch64/ld.abilist | 18 + .../mach/hurd/aarch64/libBrokenLocale.abilist |1 + sysdeps/mach/hurd/aarch64/libanl.abilist |4 + sysdep

[PATCH v2 14/20] hurd: Implement TLS on AArch64

This is using TLS_DTV_AT_TP, aka "Variant I" layout. tpidr_el0, which is both readable and writable from userspace, is used as the thread pointer. We store our Hurd-specific data (sigstate and reply port) *before* the TCB head, in a tcbprehead_t structure. This tcbprehead_t structure is also what

[PATCH v2 07/20] aarch64: Move pointer_guard.h out of sysdeps/unix/sysv/linux

Nothing about this is Linux-specific. Signed-off-by: Sergey Bugaev --- sysdeps/{unix/sysv/linux => }/aarch64/pointer_guard.h | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sysdeps/{unix/sysv/linux => }/aarch64/pointer_guard.h (100%) diff --git a/sysdeps/unix/sysv/linux/aarch64/poi

[PATCH v2 02/20] hurd: Stop relying on VM_MAX_ADDRESS

We'd like to avoid committing to a specific size of virtual address space (i.e. the value of VM_AARCH64_T0SZ) on AArch64. While the current version of GNU Mach still exports VM_MAX_ADDRESS for compatibility, we should try to avoid relying on it when we can. This piece of logic in _hurdsig_getenv

[PATCH v2 01/20] hurd: Move internal functions to internal header

Move _hurd_self_sigstate (), _hurd_critical_section_lock (), and _hurd_critical_section_unlock () inline implementations (that were already guarded by #if defined _LIBC) to the internal version of the header. While at it, add to the includes, and use __LIBC_NO_TLS () unconditionally. Signed-off-

[PATCH v2 06/20] htl: Respect GL(dl_stack_flags) when allocating stacks

Previously, HTL would always allocate non-executable stacks. This has never been noticed, since GNU Mach on x86 ignores VM_PROT_EXECUTE and makes all pages implicitly executable. Since GNU Mach on AArch64 supports non-executable pages, HTL forgetting to pass VM_PROT_EXECUTE immediately breaks any

[PATCH v2 00/20] aarch64-gnu port & GNU/Hurd on AArch64 progress

Hello! This is v2 of my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. v1 is here [0]. [0]: https://sourceware.org/pipermail/libc-alpha/2024-January/153675.html Last time, Joseph Myers has pointed out that the aarch64-gnu port can not be merged into glibc until aarch64-gnu support is

[PATCH v2 05/20] hurd: Use the RETURN_ADDRESS macro

This gives us PAC stripping on AArch64. Signed-off-by: Sergey Bugaev --- PAC is still not implemented on gnumach side, though. sysdeps/mach/hurd/init-first.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/mach/hurd/init-first.c b/sysdeps/mach/hurd/init-first.c inde

[PATCH v2 03/20] Allow glibc to be compiled without EXEC_PAGESIZE

We would like to avoid statically defining any specific page size on aarch64-gnu, and instead make sure that everything uses the dynamic page size, available via vm_page_size and GLRO(dl_pagesize). There are currently a few places in glibc that require EXEC_PAGESIZE to be defined. Per Roland's sug

Re: [PATCH gcc 1/3] Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h

On Wed, Mar 20, 2024 at 10:20 PM Thomas Schwinge wrote: > Hi! Hi Thomas, > Sergey, great work on aarch64 GNU/Hurd! (... where these GCC bits > clearly were the less complicated part...) ;-) thanks! (and indeed they were :) > Please re-submit with ChangeLog updates added to the Git commit log

[PATCH v2 1/3] Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h

Since it's not i386-specific; this makes it possible to reuse it for other architectures. Also, add a warning for the case gnu.h is specified before gnu-user.h, which would cause gnu-user's version of the spec to override gnu's, and not the other way around as it's intended. The i?86-gnu target cu

[PATCH v2 3/3] libgcc: Add basic support for aarch64-gnu (GNU/Hurd on AArch64)

There is currently no unwinding implementation. libgcc/ChangeLog: * config.host: Recognize aarch64*-*-gnu* hosts. * config/aarch64/gnu-unwind.h: New file. * config/aarch64/heap-trampoline.c (allocate_trampoline_page): Support GNU/Hurd. Signed-off-by: Sergey Bugaev

[PATCH v2 2/3] aarch64: Add support for aarch64-gnu (GNU/Hurd on AArch64)

Coupled with a corresponding binutils patch, this produces a toolchain that can sucessfully build working binaries targeting aarch64-gnu. gcc/Changelog: * config.gcc: Recognize aarch64*-*-gnu* targets. * config/aarch64/aarch64-gnu.h: New file. Signed-off-by: Sergey Bugaev --- g

Re: [PATCH 01/10] term: Fix function prototype

Sergey Bugaev, le sam. 23 mars 2024 15:12:21 +0300, a ecrit: > On Sat, Mar 23, 2024 at 3:06 PM Samuel Thibault > wrote: > > Applied the whole series, thanks! > > Looks like "[PATCH 07/10] exec: Add support for AArch64 executables" > fell through the cracks... Indeed! Sorry for the miss. Samuel

Re: [PATCH 01/10] term: Fix function prototype

On Sat, Mar 23, 2024 at 3:06 PM Samuel Thibault wrote: > Applied the whole series, thanks! Looks like "[PATCH 07/10] exec: Add support for AArch64 executables" fell through the cracks... Sergey

Re: [PATCH 01/10] term: Fix function prototype

Hello, Applied the whole series, thanks! Samuel

[PATCH 09/10] proc: Add support for AArch64 in uname

Since no CPU subtypes are defined for CPU_TYPE_ARM64, just report the type, same as for x86_64. Sample uname(2) output: sysname: GNU release: 0.9 version: GNU-Mach 1.8/Hurd-0.9 machine: aarch64 --- proc/cpu-types.c | 3 +++ proc/host.c | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions

[PATCH 01/10] term: Fix function prototype

struct bottomhalf.mdmstate is of type error_t (*)(int *state). Fixes -Wincompatible-pointer-types, which is a hard error by default in GCC 14. --- term/hurdio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/term/hurdio.c b/term/hurdio.c index c6e14a4a..eab59b72 100644 --- a/

[PATCH 06/10] exec: Stop relying on address space size

The code here just wants to deallocate the whole address space, and Mach already contains the logic to limit the passed-in range to the vm_map's actual bounds (see VM_MAP_RANGE_CHECK). --- exec/exec.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/exec/exec.c b/exec/exec.c

[PATCH 08/10] elfcore: Add support for saving AArch64 registers

--- exec/elfcore.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/exec/elfcore.c b/exec/elfcore.c index c6aa2bc8..8c85b13b 100644 --- a/exec/elfcore.c +++ b/exec/elfcore.c @@ -187,6 +187,32 @@ fetch_thread_fpregset (thread_t thread, prfpregset_t *fpregs)

[PATCH 07/10] exec: Add support for AArch64 executables

This maps to EM_AARCH64. Just like the x86_64 branch, we only compile this code if CPU_TYPE_ARM64 is defined in Mach headers, to avoid raising Mach version requirement on other architectures; and we explicitly enable the branch when building for AArch64 itself, to get a build error if CPU_TYPE_ARM

[PATCH 10/10] boot: Add support for AArch64

--- boot/userland-boot.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/boot/userland-boot.c b/boot/userland-boot.c index f407f0a6..496628eb 100644 --- a/boot/userland-boot.c +++ b/boot/userland-boot.c @@ -334,6 +334,17 @@ boot_script_exec_cmd (void *hook, thread_set_state (

[PATCH 02/10] exec: Fix creating executable stacks

The previous logic had two independent issues: * We need to make the stack executable if either the program or its ELF interpreter requires executable stack. In practice, it's common for the program itself to not require executable stack, but ld.so (glibc) needs it. * mach_setup_thread ()

[PATCH 05/10] libshouldbeinlibc: Stop relying on address space size

While GNU Mach on AArch64 still exports VM_MIN_ADDRESS / VM_MAX_ADDRESS for compatibility, we should try to rely on it less when possible; in the future we might be able to stop exporting them from Mach. The code here really just wants to wire everything in its address space, and the wire_segment_

[PATCH 03/10] Make long & friends 64-bit on 64-bit platforms

Not only on x86_64. --- hurd/hurd_types.defs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hurd/hurd_types.defs b/hurd/hurd_types.defs index 9f176fef..0086d139 100644 --- a/hurd/hurd_types.defs +++ b/hurd/hurd_types.defs @@ -425,7 +425,7 @@ type flock_t = struct { }; type

[PATCH 04/10] proc: Only try host_kernel_version () on i386

None of the new architectures are going to have it; that isn't specific to x86_64. --- proc/host.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proc/host.c b/proc/host.c index 823bda53..0197fecf 100644 --- a/proc/host.c +++ b/proc/host.c @@ -371,8 +371,8 @@ initialize_ve