[SCM] Hurd branch, master, updated. v0.9.git20231217-53-g1adea9cc

[Samuel Thibault]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, master has been updated
       via  1adea9ccce9e07037506d069a73f048b50c40561 (commit)
       via  e652799da09e4bade166476ad4cee13e49722ec9 (commit)
       via  bbb662f012ca16c53f93d9de32872a9229c87769 (commit)
       via  db46ea2eb9dc84959fbf9b1819facac3d6078ba1 (commit)
       via  a32f12f23025622b60cc33559950bc7913f59311 (commit)
       via  ddc4f0144a709cebc4dae321b810e85547856b09 (commit)
       via  0fce0a75e76fd9965dc5a868ac84e7e3adb86b71 (commit)
       via  14d294e2014b188cce8f5a79dd46cf62cd9a86aa (commit)
       via  5d7055b305624d6e271e2fc57e67aa5b65039486 (commit)
      from  64559905b30334fdae1b94b775a4a98ee0126d0c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 1adea9ccce9e07037506d069a73f048b50c40561
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:22 2024 +0300

    boot: Add support for AArch64
    
    Message-ID: <20240323115322.69075-10-bugaevc@gmail.com>

commit e652799da09e4bade166476ad4cee13e49722ec9
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:21 2024 +0300

    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
    Message-ID: <20240323115322.69075-9-bugaevc@gmail.com>

commit bbb662f012ca16c53f93d9de32872a9229c87769
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:20 2024 +0300

    elfcore: Add support for saving AArch64 registers
    
    Message-ID: <20240323115322.69075-8-bugaevc@gmail.com>

commit db46ea2eb9dc84959fbf9b1819facac3d6078ba1
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:18 2024 +0300

    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).
    Message-ID: <20240323115322.69075-6-bugaevc@gmail.com>

commit a32f12f23025622b60cc33559950bc7913f59311
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:17 2024 +0300

    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_internal () routine already queries for actually present
    memory regions dynamically.
    Message-ID: <20240323115322.69075-5-bugaevc@gmail.com>

commit ddc4f0144a709cebc4dae321b810e85547856b09
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:16 2024 +0300

    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.
    Message-ID: <20240323115322.69075-4-bugaevc@gmail.com>

commit 0fce0a75e76fd9965dc5a868ac84e7e3adb86b71
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:15 2024 +0300

    Make long & friends 64-bit on 64-bit platforms
    
    Not only on x86_64.
    Message-ID: <20240323115322.69075-3-bugaevc@gmail.com>

commit 14d294e2014b188cce8f5a79dd46cf62cd9a86aa
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:14 2024 +0300

    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 () allocates stacks with a simple vm_allocate (),
      which creates non-executable memory.  So if an executable stack is
      required, the stack has to be vm_protect'ed to enable execution, not
      the other way around.  As the comment suggest, it would've been better
      to use vm_map () with the desired protection directly.
    Message-ID: <20240323115322.69075-2-bugaevc@gmail.com>

commit 5d7055b305624d6e271e2fc57e67aa5b65039486
Author: Sergey Bugaev <bugaevc@gmail.com>
Date:   Sat Mar 23 14:53:13 2024 +0300

    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.
    Message-ID: <20240323115322.69075-1-bugaevc@gmail.com>

-----------------------------------------------------------------------

Summary of changes:
 boot/userland-boot.c     | 11 +++++++++++
 exec/elfcore.c           | 26 ++++++++++++++++++++++++++
 exec/exec.c              | 13 ++++++-------
 hurd/hurd_types.defs     |  2 +-
 libshouldbeinlibc/wire.c |  2 +-
 proc/cpu-types.c         |  3 +++
 proc/host.c              |  8 ++++----
 term/hurdio.c            |  2 +-
 8 files changed, 53 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
Hurd