On Tue, Sep 24, 2024 at 4:53 AM wrote:
> I'm game to try! How would I go about setting up a vm AArch64 image that
>
> runs the Hurd?
It's not much different from building a Hurd image for another
architecture (i686 or x86_64), other than having to use some unmerged
branches.
You should start by
GLib switching to use faccessat (F_OK) to implement
g_file_query_exists () for local files.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4272
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/faccessat.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sysdeps/mach/hurd
On Wed, Aug 21, 2024 at 7:37 PM Luca Dariz wrote:
> +#include
> +
> +static void printx(struct i386_xfloat_state *state, int size)
> +{
> + printf("xfloat init %d fp %d exc %d\n",
> + state->initialized, state->fpkind, state->exc_status);
> + struct i386_xfp_save *xfp = (struct i386_xfp
On Mon, Aug 5, 2024 at 9:23 PM Samuel Thibault wrote:
> Luca Dariz, le lun. 05 août 2024 14:52:24 +0200, a ecrit:
> > Il 05/08/24 00:32, Samuel Thibault ha scritto:
> > > Luca Dariz, le ven. 02 août 2024 17:32:34 +0200, a ecrit:
> > > > +#define XFP_STATE_BYTES (sizeof (struct i386_xfp_save))
> >
Hi Flavio,
in general, what's this useful for? Debugging, maybe?
Do you expect the process itself to query its threads' names locally,
or do you expect another process (GDB) to issue thread_get_name
remotely?
On Wed, Jul 10, 2024 at 7:04 PM Flavio Cruz wrote:
> diff --git a/htl/pt-internal.h b/
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 livestrea
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 a
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, thread_get_sta
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 make s
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 |
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()
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.
---
aarch64/Makef
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 ++
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,
AARCH64_THREAD_
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 AArch
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
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 reasons
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 al
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 t
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]: https://
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
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 al
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 mak
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 al
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 wa
---
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 MACH_MSG_TYPE_MAKE_SEND
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 particula
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 the
---
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 /* __x86_
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
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
@@
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
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
---
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 $(srcdir)/in
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
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 dele
---
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 cdb2ce13..d236712
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
--- a/tests/include/testlib.
---
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 ex
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.
---
kern/syscall_sub
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
--- a/i386/i386/lo
---
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
---
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 +30,
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 b
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 a/ipc/ipc_space.
---
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 @@
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 addressi
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.
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/a
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.
sy
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
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
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
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
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/aa
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/aarch6
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
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
_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
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 |
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
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
d long int) 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..8b192
-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
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
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
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
x27;s 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
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
The i?86-gnu target 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
---
g
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
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
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
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
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/
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
---
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)
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
---
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 (
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 ()
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_
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
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
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 +898
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
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
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, exact
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 siz
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
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.)
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 f
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 s
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 t
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 $rax=0x8
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
> > > > -ftrivial-auto-var-in
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(&fpstate, 0, sizeof(fpstate));
> +
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
other
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 so
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
That
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 need
1 - 100 of 789 matches
Mail list logo