Re: Come watch a live stream coding session for the Hurd Video

On Sun, Jun 2, 2024 at 12:22 AM Joshua Branson wrote: > So we had an awesome time today watching Sergey code a trivial translator (1) > and do > some glibc hacking (2). Sergey coded and chatted for 4 and 1/2 hours! Three > cheers > for that kind of commitment! Thanks pal! > > In the

Re: Come watch a live stream coding session for the Hurd

Hi, On Fri, May 31, 2024 at 3:18 PM Almudena Garcia wrote: > Other idea could be a magnet/torrent translator > > wget magnet:?fl=http://... > > and downloading the torrent file without a torrent client bittorrentfs would be cool indeed, and it's something that I wanted to write for a long time

Re: [PATCH 9/9] Add a test for thread state

On Tue, Apr 16, 2024 at 4:01 AM Samuel Thibault wrote: > Ah, no, I mis read the result. It does stay stuck on x86_64. Indeed, thanks. Reproduced and fixed; I was accidentally using rsp (instead of ursp) in one place. Sergey -- >8 -- This tests generating and handling exceptions,

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

Hello, On Wed, Apr 10, 2024 at 2:57 PM Florian Weimer wrote: > * Sergey Bugaev: > > > We could define EXEC_PAGESIZE to some conservative value on > > aarch64-gnu too, if it turns out that this little workaround is really > > required. But it seems cleaner to

[PATCH 9/9] Add a test for thread state

This tests generating and handling exceptions, thread_get_state(), thread_set_state(), and newly added thread_set_self_state(). It does many of the same things that glibc does when handling a signal. --- Note that I only tested this on i386 and AArch64, not on x86_64. tests/test-thread-state.c

[PATCH 3/9] aarch64: Add public syscall ABI

We use largely the same ABI as Linux: a syscall is invoked with the "svc #0" instruction, passing arguments the same way as for a regular function call. Specifically, up to 8 arguments are passed in the x0-x7 registers, and the rest are placed on the stack (this is only necessary for the vm_map()

[PATCH 5/9] aarch64: Add mach_aarch64 API

This currently contains a single RPC to get Linux-compatible hwcaps, as well as the values of MIDR_EL1 and REVIDR_EL1 system registers. In the future, this is expected to host the APIs to manage PAC keys, and possibly some sort of AArch64-specific APIs for userland IRQ handlers. ---

[PATCH 6/9] aarch64: Add exception type definitions

A few yet-unimplemented codes are also sketched out; these are included so you know roughly what to expect once the missing functionality gets implemented, but are not in any way stable or usable. --- aarch64/Makefrag.am | 1 + aarch64/include/mach/aarch64/exception.h | 90

[PATCH 8/9] Add thread_set_self_state() trap

This is a new Mach trap that sets the calling thread's state to the passed value, as if with a call to the thread_set_state() RPC. If the flavor of state being set is the one that contains the register used for syscall return value (i386_THREAD_STATE or i386_REGS_SEGS_STATE on x86,

[PATCH 7/9] aarch64: Add thread state types

Notes: * TPIDR_EL0, the TLS pointer, is included in the generic state directly. * TPIDR2_EL0, part of the SME extension, is not included in the generic state. If we add SME support, it will be a part of something like aarch64_sme_state. * CPSR is not a real register in AArch64 (unlike in

[PATCH 2/9] aarch64: Add the basics

This adds "aarch64" host support to the build system, along with some uninteresting installed headers. The empty aarch64/aarch64/ast.h header is also added to create the aarch64/aarch64/ directory (due to Git peculiarity). With this, it should be possible to run 'configure --host=aarch64-gnu' and

[PATCH 0/9] AArch64 Mach public headers

Hello! This patchset contains public headers for AArch64 support in GNU Mach, along with just enough buildsystem infrastructure to recognize and install them. It is quite similar to the "sketch" patches that I have posted in January of this year, but I have done a number of changes for two

[PATCH 4/9] aarch64: Add vm_param.h

And make it so that the generic vm_param.h doesn't require the machine- specific one to define PAGE_SIZE etc. We *don't* want a PAGE_SIZE constant to be statically exported to userland; instead userland should initialize vm_page_size by querying vm_statistics(), and then use vm_page_size. We'd

[PATCH 1/9] Add CPU_TYPE_ARM64

This is distinct from CPU_TYPE_ARM, since we're going to exclusively use AArch64 / A64, which CPU_TYPE_ARM was never meant to support, and to match EM_AARCH64, which is also separate from EM_ARM. CPU_TYPE_X86_64 was similarly made distinct from CPU_TYPE_I386. This is named CPU_TYPE_ARM64 rather

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

On Tue, Apr 9, 2024 at 7:24 PM Palmer Dabbelt wrote: > > I assume the buildbot failure that I just got an email about is > > unrelated; it's failing on some RISC-V thing. > > Sorry if I missed something here, do you have a pointer? The buildbot failure emails reference [0] and [1]. [0]:

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

On Tue, Apr 9, 2024 at 10:27 AM Thomas Schwinge wrote: > Thanks, pushed to trunk branch: > > - commit 532c57f8c3a15b109a46d3e2b14d60a5c40979d5 "Move GNU/Hurd startfile > spec from config/i386/gnu.h to config/gnu.h" > - commit 9670a2326333caa8482377c00beb65723b7b4b26 "aarch64: Add support for

[PATCH 1/3] vm: Fix use-after-free in vm_map_pageable_scan()

When operating on the kernel map, vm_map_pageable_scan() does what the code itself describes as "HACK HACK HACK HACK": it unlocks the map, and calls vm_fault_wire() with the map unlocked. This hack is required to avoid a deadlock in case vm_fault or one of its callees (perhaps, a pager) needs to

[PATCH 2/3] vm: Don't attempt to extend in-transition entries

The in-transition mechanism exists to make it possible to unlock a map while still making sure some VM entries won't disappear from under you. This is currently used by the VM copyin mechanics. Entries in this state are better left alone, and extending/coalescing is only an optimization, so it

[PATCH 3/3] vm: Mark entries as in-transition while wiring down

When operating on the kernel map, vm_map_pageable_scan() does what the code itself describes as "HACK HACK HACK HACK": it unlocks the map, and calls vm_fault_wire() with the map unlocked. This hack is required to avoid a deadlock in case vm_fault or one of its callees (perhaps, a pager) needs to

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

Hello, On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford wrote: > I don't know if you're waiting on me, but just in case: this and patch 3 > still LGTM if Thomas is OK with them. Thanks. Thomas asked me to resubmit with Changelog entries added (but hasn't pointed out anything else), so this is

[PATCH mig 2/2] Add support for MACH_MSG_TYPE_COPY_SEND_ONCE

--- cpu.sym | 2 ++ lexxer.l | 1 + 2 files changed, 3 insertions(+) diff --git a/cpu.sym b/cpu.sym index 1ac2fae..fe208c9 100644 --- a/cpu.sym +++ b/cpu.sym @@ -69,6 +69,8 @@ expr MACH_MSG_TYPE_COPY_SEND expr MACH_MSG_TYPE_MAKE_SEND /* Must hold receive rights */ expr

[PATCH gnumach 1/2] Add MACH_MSG_TYPE_COPY_SEND_ONCE

Mach allows messages to carry port rights along with data; the rights contained in a message are transferred from the sender's IPC space to the receiver. The sender has to specify exactly how a right that the message will carry is to be created from the right(s) that the sender holds: in

Re: [PATCH] elf-load: Respect PT_GNU_STACK

On Wed, Mar 27, 2024 at 9:37 PM Samuel Thibault wrote: > But it's not getting used anywhere? Indeed, I forgot to extract the kern/bootstrap.c part of the change. Ooops :) Thanks for pointing it out. Sergey -- >8 -- If a bootstrap ELF contains a PT_GNU_STACK phdr, take stack protection from

[PATCH 16/17] tests: Don't ask for executable stack

--- tests/start.S| 2 ++ tests/syscalls.S | 2 ++ 2 files changed, 4 insertions(+) diff --git a/tests/start.S b/tests/start.S index b795bfbd..15970fb9 100644 --- a/tests/start.S +++ b/tests/start.S @@ -26,3 +26,5 @@ _start: movq%rsp,%rdi callq c_start #endif /*

[PATCH 00/17] Preparatory patches

These are generic, relatively independent patches from the AArch64 branch. I've done a quick build for i386-gnu and things still seem to build, but please test! Sergey

[PATCH 04/17] Load 64-bit ELFs on all 64-bit ports

Not only on x86_64. --- include/mach/exec/elf.h | 4 ++-- kern/exception.c| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/mach/exec/elf.h b/include/mach/exec/elf.h index 42920e25..55304496 100644 --- a/include/mach/exec/elf.h +++ b/include/mach/exec/elf.h @@

[PATCH 02/17] Disable host_kernel_version() everywhere but on i386

It's not only x86_64, none of new architectures are going to have it. --- include/mach/mach_host.defs | 6 +++--- kern/host.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/mach/mach_host.defs b/include/mach/mach_host.defs index a8c40af6..8fd9d6b3

[PATCH 01/17] elf-load: Respect PT_GNU_STACK

If a bootstrap ELF contains a PT_GNU_STACK phdr, take stack protection from there. Otherwise, default to VM_PROT_ALL. --- include/mach/exec/elf.h | 1 + include/mach/exec/exec.h | 2 ++ kern/elf-load.c | 7 +++ 3 files changed, 10 insertions(+) diff --git a/include/mach/exec/elf.h

[PATCH 17/17] tests: Create tests/ in the build tree before trying to use it

--- tests/user-qemu.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/user-qemu.mk b/tests/user-qemu.mk index fd5ae1ab..4f8390b6 100644 --- a/tests/user-qemu.mk +++ b/tests/user-qemu.mk @@ -130,6 +130,7 @@ SRC_TESTLIB= \ $(MIG_GEN_CC) tests/errlist.c: $(addprefix

[PATCH 05/17] gsync: Use copyin()/copyout() to access user memory

Depending on the architecture and setup, it may not be possible to access user memory directly, for example, due to user mode mappings not being accessible from kernel mode (x86 SMAP, AArch64 PAN). There are dedicated machine-specific copyin()/copyout() routines that know how to access user memory

[PATCH 07/17] kern/rdxtree: Fix undefined behavior

Initializing a variable with itself is undefined, and GCC 14 rightfully produces a warning about the variable being used (to initialize itself) prior to initialization. X15 sets the variables to 0 instead, so do the same in Mach. --- kern/rdxtree.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 12/17] tests: Add a more serious mach_msg_server() routine

--- tests/include/testlib.h | 16 ++ tests/test-syscalls.c | 40 + tests/testlib.c | 123 3 files changed, 142 insertions(+), 37 deletions(-) diff --git a/tests/include/testlib.h b/tests/include/testlib.h index

[PATCH 11/17] tests: Fix halt()

Mark it as noreturn, and make sure to halt, not reboot. --- tests/include/testlib.h | 2 +- tests/testlib.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/include/testlib.h b/tests/include/testlib.h index a3f3a6a8..cdb2ce13 100644 ---

[PATCH 15/17] tests: Make exception subcode a long

--- tests/test-syscalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/test-syscalls.c b/tests/test-syscalls.c index 63c2690a..fbfecd9c 100644 --- a/tests/test-syscalls.c +++ b/tests/test-syscalls.c @@ -34,7 +34,7 @@ static struct { mach_port_t task; integer_t

[PATCH 06/17] kern/syscall_subr.c: Use copyin()/copyout() to access user memory

It's not always possible to directly access user memory from kernel mode. While it's in theory a lot more expensive to fetch each character to be printed separately, mach_print() is only a debugging facility, and it's not supposed to be used for printing large amounts of data. ---

[PATCH 09/17] Move copy{in,out}msg declarations to copy_user.h

Since they are implemented in copy_user.c --- i386/i386/locore.h | 4 ipc/copy_user.h| 15 +++ kern/exception.c | 1 + 3 files changed, 16 insertions(+), 4 deletions(-) diff --git a/i386/i386/locore.h b/i386/i386/locore.h index 217e6dec..8ff587ed 100644 ---

[PATCH 13/17] tests: Add vm_page_size

--- tests/include/testlib.h | 2 ++ tests/testlib.c | 13 + 2 files changed, 15 insertions(+) diff --git a/tests/include/testlib.h b/tests/include/testlib.h index d2367124..035fdc28 100644 --- a/tests/include/testlib.h +++ b/tests/include/testlib.h @@ -70,6 +70,8 @@ thread_t

[PATCH 14/17] tests: Use vm_page_size

--- tests/testlib_thread_start.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/tests/testlib_thread_start.c b/tests/testlib_thread_start.c index fa8af0ea..df4b19ab 100644 --- a/tests/testlib_thread_start.c +++ b/tests/testlib_thread_start.c @@ -30,30

[PATCH 10/17] Make -fno-PIE etc. architecture-dependent

There might be good reasons why Mach on x86 shouldn't be built as PIC/ PIE, but there are also very good reasons to support PIE on other architectures. Potentially implementing KASLR is one such reason; but also the Linux AArch64 boot protocol (that the AArch64 port will use for booting) lets the

[PATCH 08/17] ipc: Turn ipc_entry_lookup_failed() into a macro

ipc_entry_lookup_failed() is used with both mach_msg_user_header_t and mach_msg_header_t arguments, which are different types. Make it into a macro, so it works with both. --- ipc/ipc_space.h | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git

[PATCH 03/17] Use the x86_64 message ABI on all 64-bit ports

--- include/mach/message.h | 10 +- ipc/ipc_kmsg.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/include/mach/message.h b/include/mach/message.h index 9790ef98..87b83951 100644 --- a/include/mach/message.h +++ b/include/mach/message.h @@ -240,7 +240,7

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

Hello, On Mon, Mar 25, 2024 at 2:58 PM Florian Weimer wrote: > > I think the intent here is to initialize _dl_pagesize with a > > conservative default, to avoid initialization ordering issues. > > EXEC_PAGESIZE is supposed to be largest supported page size. > > This was committed without

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

to be an easy way to feature-test, in a header, for existence of traps in the Mach version being built against. Instead, just declare the trap prototype unconditionally, and don't add an exported version for now. Signed-off-by: Sergey Bugaev --- sysdeps/mach/include/mach/mach_traps.h | 7

[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/aarch6

[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

[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

[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

[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

[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

[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

[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

[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

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

the _dl_start_user label pointing to an earlier instruction. Signed-off-by: Sergey Bugaev --- sysdeps/aarch64/dl-start.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/aarch64/dl-start.S b/sysdeps/aarch64/dl-start.S index d645484e..e35431ca 100644 --- a/sysdeps/aarch64/dl

[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

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

also what THREAD_SELF, THREAD_GETMEM, and THREAD_SETMEM macros access. Signed-off-by: Sergey Bugaev --- .../mach/hurd/aarch64/dl-tls-initialized.c| 19 ++ sysdeps/mach/hurd/aarch64/tls.h | 206 ++ 2 files changed, 225 insertions(+) create mode 100644 sysdeps

[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/a

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

) and not just (long int), since the type of struct hurd_signal_preemptor.{first,last} is unsigned long int. Signed-off-by: Sergey Bugaev --- hurd/hurdsig.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/hurd/hurdsig.c b/hurd/hurdsig.c index 882a0347..8b1928d1 100644

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

-by: Sergey Bugaev --- This is the remaining part of the "hurd: Add some missing includes" patch from v1, redone in a different way, as discussed last time. The hurd/check-installed-headers-c test seems to pass for me, but please check on your end too. hurd/hurd/signal.h

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

any code that (unfortunately, still) relies on executable stacks. Signed-off-by: Sergey Bugaev --- sysdeps/htl/Versions | 4 sysdeps/mach/htl/pt-stack-alloc.c | 9 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/sysdeps/htl/Versions b/sysdeps/htl/Versions

[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

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

suggestion [0], drop the static GLRO(dl_pagesize) initializers (for now, only if EXEC_PAGESIZE is not defined), and don't require EXEC_PAGESIZE definition for libio to enable mmap usage. [0]: https://mail.gnu.org/archive/html/bug-hurd/2011-10/msg00035.html Signed-off-by: Sergey Bugaev --- Same

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

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

currently specifies them in the right order, but it's easy to accidentally put them in a wrong order. gcc/Changelog: * config/i386/gnu.h: Move GNU/Hurd STARTFILE_SPEC from here... * config/gnu.h: ...to here. Signed-off-by: Sergey Bugaev --- gcc/config/gnu.h | 16

[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

[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

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

[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

[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 ---

[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

[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

[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 { };

[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 @@

Re: [PATCH] console-client: deallocate the port once finished with it

On Wed, Mar 13, 2024 at 1:56 PM Etienne Brateau wrote: > console-client/trans.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/console-client/trans.c b/console-client/trans.c > index b7d56cb0..a3d6dd3c 100644 > --- a/console-client/trans.c > +++ b/console-client/trans.c > @@ -898,6

Re: [RFC PATCH 00/23] aarch64-gnu port

On Mon, Mar 11, 2024 at 4:48 PM H.J. Lu wrote: > I think hurd maintainers can approve and check in all hurd specific > changes now even if they won't build. The generic changes should > be looked at more closely so that they have no impacts on any > future Linux changes and future Linux changes

Re: [PATCH 1/3 gnumach] vm_map: Fix deadlock in vm code

On Wed, Feb 21, 2024 at 9:44 PM Samuel Thibault wrote: > Damien Zammit, le mer. 21 févr. 2024 13:45:59 +, a ecrit: > > Authored-by: Sergey Bugaev > IIRC you got to see which kind of deadlock we are protecting from here? > I'd be very useful to document it here, so next

Re: [PATCH gnumach] Add vm_pages_phys

On Wed, Jan 31, 2024 at 2:44 PM Samuel Thibault wrote: > > I see you used kmem_alloc_pageable() over kmem_alloc() that I > > suggested. Why is that? > > Because I have seen it used so in other places, > notably host_ipc_marequest_info, host_slab_info, > host_virtual_physical_table_info Yes,

Re: [PATCH gnumach] Add vm_pages_phys

On Tue, Jan 30, 2024 at 9:45 PM Samuel Thibault wrote: > > > +kern_return_t vm_pages_phys( > > > + host_t host, > > > + vm_map_tmap, > > > + vm_address_taddress, > > > + vm_size_t

Re: [PATCH gnumach] Add vm_pages_phys

Hello, On Mon, Jan 29, 2024 at 11:59 PM Samuel Thibault wrote: > Please notably review the RPC part, I really don't know that much about > mig. Some nitpicks inline. Flávio, does what I'm saying below make sense to you? > +/* > + * vm_pages_phys returns information about a region of memory

Re: [PATCH v2 2/4] Avoid conflicting types for 'copy_file_range'

On Mon, Jan 22, 2024 at 9:23 PM Sergey Bugaev wrote: > call such a function. For example on GNU/Linux, remove(2) is a stub, (That was supposed to say revoke(2), of course.)

Re: [PATCH v2 2/4] Avoid conflicting types for 'copy_file_range'

Hello, On Mon, Jan 22, 2024 at 8:05 PM Peter Maydell wrote: > > On Thu, 18 Jan 2024 at 16:03, Manolo de Medici > wrote: > > > > Compilation fails on systems where copy_file_range is already defined as a > > stub. > > What do you mean by "stub" here ? If the system headers define > a prototype

Re: Announcing: a new Hurd distro, based on Alpine Linux

On Sun, Jan 21, 2024 at 10:14 PM wrote: > I'd be happy to buy a sourcehut account for it for a year. > > I'd also be happy to create a website for it and host it for a year. > We should make this email (perhaps reword it) as the website's first > blog post. > > Software with which we can build a

Announcing: a new Hurd distro, based on Alpine Linux

Hello! Those of you who made it to Joshua's belated New Year's party have heard me mumble my way through announcing this: I have been working on a new Hurd-based disto, based on the Alpine Linux distribution [0]! [0] https://www.alpinelinux.org/about/ Now, before I go any further, I should say

Re: [PATCH 03/14] add mach_host tests

On Sat, Jan 6, 2024 at 10:26 PM Luca wrote: > Uhm, I still have an issue, although a bit different now: > > By the way, the exception is still the same (General Protection, which > is usually forwarded to user space), but for a different reason, > apparently a non-canonical address in

Re: [PATCH 03/14] add mach_host tests

On Sat, Jan 6, 2024 at 9:45 PM Samuel Thibault wrote: > > Luca, le sam. 06 janv. 2024 19:41:17 +0100, a ecrit: > > Il 29/12/23 15:14, Luca Dariz ha scritto: > > > Il 29/12/23 14:44, Samuel Thibault ha scritto: > > > > Also, it would be useful to compile the tests with > > > >

Re: 64bit startup

On Sat, Jan 6, 2024 at 2:42 AM Luca wrote: > I had this small patch applied that apparently is enough for me to have > some kind of core dump, I'm not sure if it's a good solution: > +#ifdef __x86_64__ > + struct _libc_fpstate fpstate; > + memset(, 0, sizeof(fpstate)); > +

Re: 64bit startup

I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Could you please either teach me where to look, or if they're indeed missing, upload them? Also I can't help but notice that the hurd package (i.e the translator binaries) is still not being built as PIE, unlike basically all the

Re: TODO-list

On Fri, Jan 5, 2024 at 2:09 AM Samuel Thibault wrote: > This is a TODO-list of mostly not-sexy things, but that we do want to > work on, because at some point it can be a question of survival of the > whole Hurd ecosystem (e.g. y2038 really is a concern). You may want to add moving off ext2 to

Re: 64bit startup

On Fri, Jan 5, 2024 at 12:52 AM Samuel Thibault wrote: > Which kind of activity? I just had a loop spawning /bin/true — this should've triggered it assuming it was related to some state getting corrupted on context-switching. > I use > > while true ; do apt install --reinstall wdiff ; done

Re: 64bit startup

On Thu, Jan 4, 2024 at 10:57 AM Samuel Thibault wrote: > > Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit: > > perhaps I need to try two of them in parallel and some I/O-heavy > > workload in the background, as you're saying. > > Yes, that's needed

Re: 64bit startup

On Wed, Jan 3, 2024 at 10:07 PM Luca wrote: > Hi Sergey, Hi, > Recently I've been installing hurd-amd64 on another disk of my hurd-i386 > vm and booting from that. Basically I prepare the disk with debootstrap > --foreign, then I reuse the i386 grub install to boot the 64 bit kernel > with a

Re: [PATCH 01/23] hurd: Add some missing includes

On Thu, Jan 4, 2024 at 12:08 AM Sergey Bugaev wrote: > This is testing installed headers, isn't it? — then > how come sysdeps/hurd/include/hurd.h is what gets found for ? > I'm rather sure the installed is a different file. So it > would look like the test setup is broken, and thi

Re: [PATCH 01/23] hurd: Add some missing includes

On Wed, Jan 3, 2024 at 11:43 PM Samuel Thibault wrote: > Sergey Bugaev, le mer. 03 janv. 2024 20:14:34 +0300, a ecrit: > > diff --git a/sysdeps/hurd/include/hurd.h b/sysdeps/hurd/include/hurd.h > > index 568092d6..189fd44e 100644 > > --- a/sysdeps/hurd/include/hurd.h &

Re: 64bit startup

On Wed, Jan 3, 2024 at 11:27 AM Samuel Thibault wrote: > Sergey Bugaev, le mer. 03 janv. 2024 11:17:53 +0300, a ecrit: > > I guess this is where I ask (consistent with the subject line) about > > how I would run the x86_64 system (to reproduce & debug this). > > Y

Re: [RFC PATCH 00/23] aarch64-gnu port

On Wed, Jan 3, 2024 at 8:30 PM Joseph Myers wrote: > I think the same principle applies for ports to new (architecture, Hurd) > pairs as for new (architecture, Linux) pairs: the relevant code needs to > be in upstream mainline of all components on which glibc build-depends > before the port can

  1   2   3   4   5   6   7   8   >