| Message ID | 20240103171502.1358371-1-bugaevc@gmail.com |
|---|---|
| Headers | show |
| Series | aarch64-gnu port | expand |
On Wed, 3 Jan 2024, Sergey Bugaev wrote: > To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), > and GNU Mach headers for AArch64. I have posted the patches for > binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches > are required to build aarch64-gnu-mig. > There is no AArch64 port of GNU Mach yet; I'm trying to get the ball > rolling by making this port of glibc. I have only added some AArch64 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 go into glibc (and thus before the symbol versions for the port can be determined) - and at the point where it's ready to go in, a corresponding build-many-glibcs.py entry should be added as part of the patch series. Parts of <https://sourceware.org/glibc/wiki/NewPorts> may be applicable, though that's more oriented to the case where the architecture support itself is entirely new. You can of course do refactors of existing files not specific to aarch64-gnu, in preparation for the port, before then, to reduce the size of the eventual patch series proposing adding the port to glibc.
On Wed, Jan 3, 2024 at 8:30 PM Joseph Myers <jsm@polyomino.org.uk> 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 go into glibc (and thus before the symbol versions for > the port can be determined) - and at the point where it's ready to go in, > a corresponding build-many-glibcs.py entry should be added as part of the > patch series. Parts of <https://sourceware.org/glibc/wiki/NewPorts> may > be applicable, though that's more oriented to the case where the > architecture support itself is entirely new. > > You can of course do refactors of existing files not specific to > aarch64-gnu, in preparation for the port, before then, to reduce the size > of the eventual patch series proposing adding the port to glibc. Certainly; and I should've been more clear about this: I don't expect this to get merged until there's a gnumach port. And the port development, and the feedback I'm hoping to get, will likely require changes/tweaks to the Mach headers/APIs (as I've said, my versions I've developed this against are more like preliminary sketches than final APIs set in stone) and the corresponding changes to this port, so I don't expect it to be merged until that all is settled. Some generic improvements could be merged now as you're saying, but other than that, I'm posting these patches both to gather feedback from both Hurd and glibc communities, and to enable others to build it, experiment with it, and build more stuff on top of it (for example, can we get all of the Hurd building?). Symbol versions, I have set to 2.39, but seeing how the 2.39 release is already in progress, we'll likely need to bump this. Sergey
On Wed, Jan 3, 2024 at 9:15 AM Sergey Bugaev <bugaevc@gmail.com> wrote: > > Hello! > > This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. > > To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), > and GNU Mach headers for AArch64. I have posted the patches for > binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches > are required to build aarch64-gnu-mig. > > glibc fully builds and produces all the exepected libraries (including > libmvec) and binaries. It can then be used to build other programs, in > particular many core Hurd servers seem to build just fine. > > There is no AArch64 port of GNU Mach yet; I'm trying to get the ball > rolling by making this port of glibc. I have only added some AArch64 > headers to GNU Mach, but no actual runnable code. My versions of > <mach/aarch64/exception.h>, <mach/aarch64/thread_status.h> (and others) > are by no means final, they are more of preliminary sketches of the API > so I have something to port glibc against. If there are changes > resulting from discussions and (hopefully) an eventual Mach AArch64 > port, we'll need to make corresponding changes to glibc. > > There not being a Mach build means that it's not currently possible to > run or test any of this port on a real Mach. It is possible to run > simple statically linked executables on Linux (or, I guess, other > kernels which use ELF and similar enough ABI wrt how the arguments are > placed on the stack) as long as you emulate the syscalls and RPCs in > some way. I have done that, and verified that simple statically linked > executables in the bootstrap configuration (i.e. without a Hurd exec > server, with arguments already placed on the stack by Mach) start up > fine. > > I have also done a quick i686-gnu build (to see if static-start.S or > init-first.c changes have broken something), and a statically linked > hello world seems to still work as expected. > > As usual, the disclaimer about me not knowing what I'm doing: I don't! > I especially am not at all familiar with AArch64, even less so than with > x86_64. I could have done something incredibly stupid; please do review! > > That being said, these changes seem smaller and a lot less radical than > the x86_64 port patchset; they're mostly adding things rather than > reworking them, so there is less of a chance to break the x86 targets. > Evidently, we've done enough rewrokings and portability fixes (notably, > various 64-bit fixes) during the x86_64 port to make it easier to add > new ports. This port itself continues this trend somewhat too, with > init-first.c now finally becoming only sysdeps/mach/hurd -specific, and > HTL gaining support for TLS_DTV_AT_TP. > > As I said in the previous letter on bug-hurd, the hardware hardening > features (BTI, MTE, PAC) are currently "not really supported", but I do > want to support them in the future. I'm extremely interested in getting > feedback or suggestions about these. For example: what should our API > for controlling PAC keys look like, should we just allow userland to > read and write all the keys? Are there, for example, any gotchas with > BTI that we need to be aware of? Is it possible to start using PAC after > initial start-up (once /dev/random becomes available, so PAC keys can be > initialized) — how would we do that without crashing on e.g. ret > pointers that have not been encrypted? > > Finally, a couple of words about the page size. My plan is for userland > to not assume any static value of page size, and always query it > dynamically, unlike on x86, even though GNU Mach will likely be compiled > with some fixed value of page size; my understanding is this is also how > things are done on GNU/Linux. To that end, I've tried to reduce the > reliance on <mach/vm_param.h> and on EXEC_PAGESIZE being defined. > Currently, Mach headers still define *something* named PAGE_SIZE > unconditionally, causing __mach_init () to pick it up and use it instead > of querying the page size dynamically. We should make sure this does not > happen (i.e. <mach/vm_param.h> should not define PAGE_SIZE on AArch64), > this is just something I haven't figured out a nice way to fix yet. > > Sergey > > P.S. I have not forgotten about my other unmerged patch series! (Most > importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I > hope to find some time to hack on them, hopefully some time soon. > > Sergey Bugaev (23): > hurd: Add some missing includes > hurd: Declare _hurd_intr_rpc_msg* with protected visibility > Allow glibc to be compiled without EXEC_PAGESIZE > mach: Drop some unnecessary vm_param.h includes > hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now > mach: Drop SNARF_ARGS macro > hurd: Pass the data pointer to _hurd_stack_setup explicitly > hurd: Drop x86-specific assembly from init-first.c > hurd: Make init-first.c no longer x86-specific > hurd: Only init early static TLS if it's used to store stack or > pointer guards > hurd: Initializy _dl_pagesize early in static builds > aarch64: Make cpu-features definitions not Linux-specific > aarch64: Add dl-procinfo > aarch64: Allow building without kernel support for BTI > mach: Add a basic AArch64 port > hurd: Add a basic AArch64 port > hurd: Implement TLS on AArch64 > hurd: Implement longjmp for AArch64 > Add FPE_FLTIDO > hurd: Add an AArch64 signal implementation > htl: Implement some support for TLS_DTV_AT_TP > htl: Add an AArch64 implementation > hurd: Add expected aarch64-gnu abistlists > > bits/siginfo-consts.h | 4 +- > elf/dl-support.c | 6 +- > elf/rtld.c | 2 + > htl/pt-create.c | 2 + > hurd/hurdsig.c | 8 +- > libio/libioP.h | 2 +- > mach/Makefile | 1 + > mach/lowlevellock.h | 1 + > mach/setup-thread.c | 1 - > .../sysv/linux => }/aarch64/cpu-features.h | 0 > sysdeps/aarch64/dl-bti.c | 10 + > sysdeps/aarch64/dl-procinfo.c | 59 + > sysdeps/aarch64/dl-procinfo.h | 38 + > 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/aarch64/htl/tcb-offsets.sym | 5 + > .../sysv/linux => }/aarch64/libc-start.c | 0 > sysdeps/htl/dl-thread_gscope_wait.c | 16 +- > sysdeps/hurd/include/hurd.h | 1 + > sysdeps/hurd/include/hurd/signal.h | 1 + > sysdeps/mach/aarch64/bits/mach/param.h | 24 + > sysdeps/mach/aarch64/cpu-features.c | 109 + > sysdeps/mach/aarch64/sys/ucontext.h | 73 + > sysdeps/mach/aarch64/sysdep.h | 45 + > sysdeps/mach/aarch64/thread_state.h | 44 + > sysdeps/mach/configure | 1 + > sysdeps/mach/configure.ac | 1 + > sysdeps/mach/hurd/aarch64/Implies | 3 + > sysdeps/mach/hurd/aarch64/Makefile | 24 + > sysdeps/mach/hurd/aarch64/____longjmp_chk.S | 173 ++ > sysdeps/mach/hurd/aarch64/__longjmp.S | 150 ++ > sysdeps/mach/hurd/aarch64/bits/sigcontext.h | 96 + > .../mach/hurd/aarch64/dl-tls-initialized.c | 19 + > sysdeps/mach/hurd/aarch64/exc2signal.c | 119 + > sysdeps/mach/hurd/aarch64/htl/pt-machdep.c | 55 + > sysdeps/mach/hurd/aarch64/htl/pt-setup.c | 80 + > sysdeps/mach/hurd/aarch64/intr-msg.h | 123 + > sysdeps/mach/hurd/aarch64/ld.abilist | 18 + > .../mach/hurd/aarch64/libBrokenLocale.abilist | 1 + > sysdeps/mach/hurd/aarch64/libanl.abilist | 4 + > sysdeps/mach/hurd/aarch64/libc.abilist | 2123 +++++++++++++++++ > .../hurd/aarch64/libc_malloc_debug.abilist | 26 + > sysdeps/mach/hurd/aarch64/libdl.abilist | 0 > sysdeps/mach/hurd/aarch64/libm.abilist | 1030 ++++++++ > sysdeps/mach/hurd/aarch64/libmvec.abilist | 75 + > sysdeps/mach/hurd/aarch64/libpthread.abilist | 165 ++ > sysdeps/mach/hurd/aarch64/libresolv.abilist | 55 + > sysdeps/mach/hurd/aarch64/librt.abilist | 33 + > sysdeps/mach/hurd/aarch64/longjmp-ts.c | 50 + > sysdeps/mach/hurd/aarch64/shlib-versions | 2 + > sysdeps/mach/hurd/aarch64/signal-defines.sym | 10 + > sysdeps/mach/hurd/aarch64/static-start.S | 52 + > sysdeps/mach/hurd/aarch64/tls.h | 206 ++ > sysdeps/mach/hurd/aarch64/trampoline.c | 327 +++ > sysdeps/mach/hurd/aarch64/vm_param.h | 24 + > sysdeps/mach/hurd/dl-sysdep.c | 3 +- > sysdeps/mach/hurd/htl/pt-sysdep.c | 9 + > sysdeps/mach/hurd/i386/static-start.S | 3 + > sysdeps/mach/hurd/{x86 => }/init-first.c | 45 +- > sysdeps/mach/hurd/mig-reply.c | 1 + > sysdeps/mach/hurd/mmap.c | 2 +- > sysdeps/mach/hurd/x86_64/static-start.S | 1 + > sysdeps/mach/sysdep.h | 7 - > sysdeps/mach/x86/sysdep.h | 14 - > 66 files changed, 5639 insertions(+), 56 deletions(-) > rename sysdeps/{unix/sysv/linux => }/aarch64/cpu-features.h (100%) > create mode 100644 sysdeps/aarch64/dl-procinfo.c > create mode 100644 sysdeps/aarch64/dl-procinfo.h > create mode 100644 sysdeps/aarch64/htl/Makefile > create mode 100644 sysdeps/aarch64/htl/bits/pthreadtypes-arch.h > create mode 100644 sysdeps/aarch64/htl/machine-sp.h > create mode 100644 sysdeps/aarch64/htl/pt-machdep.h > create mode 100644 sysdeps/aarch64/htl/tcb-offsets.sym > rename sysdeps/{unix/sysv/linux => }/aarch64/libc-start.c (100%) > create mode 100644 sysdeps/mach/aarch64/bits/mach/param.h > create mode 100644 sysdeps/mach/aarch64/cpu-features.c > create mode 100644 sysdeps/mach/aarch64/sys/ucontext.h > create mode 100644 sysdeps/mach/aarch64/sysdep.h > create mode 100644 sysdeps/mach/aarch64/thread_state.h > create mode 100644 sysdeps/mach/hurd/aarch64/Implies > create mode 100644 sysdeps/mach/hurd/aarch64/Makefile > create mode 100644 sysdeps/mach/hurd/aarch64/____longjmp_chk.S > create mode 100644 sysdeps/mach/hurd/aarch64/__longjmp.S > create mode 100644 sysdeps/mach/hurd/aarch64/bits/sigcontext.h > create mode 100644 sysdeps/mach/hurd/aarch64/dl-tls-initialized.c > create mode 100644 sysdeps/mach/hurd/aarch64/exc2signal.c > create mode 100644 sysdeps/mach/hurd/aarch64/htl/pt-machdep.c > create mode 100644 sysdeps/mach/hurd/aarch64/htl/pt-setup.c > create mode 100644 sysdeps/mach/hurd/aarch64/intr-msg.h > create mode 100644 sysdeps/mach/hurd/aarch64/ld.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libBrokenLocale.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libanl.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libc.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libc_malloc_debug.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libdl.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libm.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libmvec.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libpthread.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/libresolv.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/librt.abilist > create mode 100644 sysdeps/mach/hurd/aarch64/longjmp-ts.c > create mode 100644 sysdeps/mach/hurd/aarch64/shlib-versions > create mode 100644 sysdeps/mach/hurd/aarch64/signal-defines.sym > create mode 100644 sysdeps/mach/hurd/aarch64/static-start.S > create mode 100644 sysdeps/mach/hurd/aarch64/tls.h > create mode 100644 sysdeps/mach/hurd/aarch64/trampoline.c > create mode 100644 sysdeps/mach/hurd/aarch64/vm_param.h > rename sysdeps/mach/hurd/{x86 => }/init-first.c (87%) > > 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 won't be blocked because of hurd.
> On Jan 3, 2024, at 21:14, Sergey Bugaev <bugaevc@gmail.com> wrote: > > Hello! > > This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. > > To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), > and GNU Mach headers for AArch64. I have posted the patches for > binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches > are required to build aarch64-gnu-mig. > > glibc fully builds and produces all the exepected libraries (including > libmvec) and binaries. It can then be used to build other programs, in > particular many core Hurd servers seem to build just fine. > > There is no AArch64 port of GNU Mach yet; I'm trying to get the ball > rolling by making this port of glibc. I have only added some AArch64 > headers to GNU Mach, but no actual runnable code. My versions of > <mach/aarch64/exception.h>, <mach/aarch64/thread_status.h> (and others) > are by no means final, they are more of preliminary sketches of the API > so I have something to port glibc against. If there are changes > resulting from discussions and (hopefully) an eventual Mach AArch64 > port, we'll need to make corresponding changes to glibc. > > There not being a Mach build means that it's not currently possible to > run or test any of this port on a real Mach. It is possible to run > simple statically linked executables on Linux (or, I guess, other > kernels which use ELF and similar enough ABI wrt how the arguments are > placed on the stack) as long as you emulate the syscalls and RPCs in > some way. I have done that, and verified that simple statically linked > executables in the bootstrap configuration (i.e. without a Hurd exec > server, with arguments already placed on the stack by Mach) start up > fine. > > I have also done a quick i686-gnu build (to see if static-start.S or > init-first.c changes have broken something), and a statically linked > hello world seems to still work as expected. > > As usual, the disclaimer about me not knowing what I'm doing: I don't! > I especially am not at all familiar with AArch64, even less so than with > x86_64. I could have done something incredibly stupid; please do review! > > That being said, these changes seem smaller and a lot less radical than > the x86_64 port patchset; they're mostly adding things rather than > reworking them, so there is less of a chance to break the x86 targets. > Evidently, we've done enough rewrokings and portability fixes (notably, > various 64-bit fixes) during the x86_64 port to make it easier to add > new ports. This port itself continues this trend somewhat too, with > init-first.c now finally becoming only sysdeps/mach/hurd -specific, and > HTL gaining support for TLS_DTV_AT_TP. > > As I said in the previous letter on bug-hurd, the hardware hardening > features (BTI, MTE, PAC) are currently "not really supported", but I do > want to support them in the future. I'm extremely interested in getting > feedback or suggestions about these. For example: what should our API > for controlling PAC keys look like, should we just allow userland to > read and write all the keys? Are there, for example, any gotchas with > BTI that we need to be aware of? Is it possible to start using PAC after > initial start-up (once /dev/random becomes available, so PAC keys can be > initialized) — how would we do that without crashing on e.g. ret > pointers that have not been encrypted? > > Finally, a couple of words about the page size. My plan is for userland > to not assume any static value of page size, and always query it > dynamically, unlike on x86, even though GNU Mach will likely be compiled > with some fixed value of page size; my understanding is this is also how > things are done on GNU/Linux. To that end, I've tried to reduce the > reliance on <mach/vm_param.h> and on EXEC_PAGESIZE being defined. > Currently, Mach headers still define *something* named PAGE_SIZE > unconditionally, causing __mach_init () to pick it up and use it instead > of querying the page size dynamically. We should make sure this does not > happen (i.e. <mach/vm_param.h> should not define PAGE_SIZE on AArch64), > this is just something I haven't figured out a nice way to fix yet. > > Sergey > > P.S. I have not forgotten about my other unmerged patch series! (Most > importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I > hope to find some time to hack on them, hopefully some time soon. > > Sergey Bugaev (23): > hurd: Add some missing includes > hurd: Declare _hurd_intr_rpc_msg* with protected visibility > Allow glibc to be compiled without EXEC_PAGESIZE > mach: Drop some unnecessary vm_param.h includes > hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now > mach: Drop SNARF_ARGS macro > hurd: Pass the data pointer to _hurd_stack_setup explicitly > hurd: Drop x86-specific assembly from init-first.c > hurd: Make init-first.c no longer x86-specific > hurd: Only init early static TLS if it's used to store stack or > pointer guards > hurd: Initializy _dl_pagesize early in static builds > aarch64: Make cpu-features definitions not Linux-specific > aarch64: Add dl-procinfo > aarch64: Allow building without kernel support for BTI > mach: Add a basic AArch64 port > hurd: Add a basic AArch64 port > hurd: Implement TLS on AArch64 > hurd: Implement longjmp for AArch64 > Add FPE_FLTIDO > hurd: Add an AArch64 signal implementation > htl: Implement some support for TLS_DTV_AT_TP > htl: Add an AArch64 implementation > hurd: Add expected aarch64-gnu abistlists Hi Sergey, Would you please update and re-post your patch series, so that reviewers can check that it doesn't break existing targets? We (Linaro) had our pre-commit CI down in late December / early January, so most of your patches weren't tested, see [1]. [1] https://patchwork.sourceware.org/project/glibc/list/?series=29086 Thank you, -- Maxim Kuvyrkov https://www.linaro.org
On Mon, Mar 11, 2024 at 4:48 PM H.J. Lu <hjl.tools@gmail.com> 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 won't be blocked > because of hurd. On Mon, Mar 11, 2024 at 5:15 PM Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote: > Hi Sergey, > > Would you please update and re-post your patch series, so that reviewers can check that it doesn't break existing targets? Hi Maxim, H.J., "Even if they won't build" won't stay that way for long: since the time I posted this glibc patchset, I've been working on porting GNU Mach to AArch64, and while that work is not yet upstream, my branch of gnumach compiles, boots in QEMU, and passes the testsuite! (And I am *so* excited about this!) Moreover, the simple glibc-based program that I've used for testing in GDB (as mentioned in the cover letter) starts up and reaches main() too! I have not rebuilt it since then, meaning that ABI indeed matches between the kernel and this glibc patchset. So yes, it might be the time for me to rebase & update this patchset, and post it again. I'll start working on that then. By the way, while I have a somewhat better understanding of AArch64 & ARM-based systems now, I'd still appreciate any reviews / insights / pointers. Sergey
* Joseph Myers: > On Wed, 3 Jan 2024, Sergey Bugaev wrote: > >> To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), >> and GNU Mach headers for AArch64. I have posted the patches for >> binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches >> are required to build aarch64-gnu-mig. > >> There is no AArch64 port of GNU Mach yet; I'm trying to get the ball >> rolling by making this port of glibc. I have only added some AArch64 > > 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 go into glibc (and thus before the symbol versions for > the port can be determined) - and at the point where it's ready to go in, > a corresponding build-many-glibcs.py entry should be added as part of the > patch series. Parts of <https://sourceware.org/glibc/wiki/NewPorts> may > be applicable, though that's more oriented to the case where the > architecture support itself is entirely new. > > You can of course do refactors of existing files not specific to > aarch64-gnu, in preparation for the port, before then, to reduce the size > of the eventual patch series proposing adding the port to glibc. I would like to stress what Joseph says here. You don't need to demonstrate actual usage or something like that, just follow the new port process (upstreamed changes in the glibc build dependencies etc.). Thanks, Florian
Hello! This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM. To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), and GNU Mach headers for AArch64. I have posted the patches for binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches are required to build aarch64-gnu-mig. glibc fully builds and produces all the exepected libraries (including libmvec) and binaries. It can then be used to build other programs, in particular many core Hurd servers seem to build just fine. There is no AArch64 port of GNU Mach yet; I'm trying to get the ball rolling by making this port of glibc. I have only added some AArch64 headers to GNU Mach, but no actual runnable code. My versions of <mach/aarch64/exception.h>, <mach/aarch64/thread_status.h> (and others) are by no means final, they are more of preliminary sketches of the API so I have something to port glibc against. If there are changes resulting from discussions and (hopefully) an eventual Mach AArch64 port, we'll need to make corresponding changes to glibc. There not being a Mach build means that it's not currently possible to run or test any of this port on a real Mach. It is possible to run simple statically linked executables on Linux (or, I guess, other kernels which use ELF and similar enough ABI wrt how the arguments are placed on the stack) as long as you emulate the syscalls and RPCs in some way. I have done that, and verified that simple statically linked executables in the bootstrap configuration (i.e. without a Hurd exec server, with arguments already placed on the stack by Mach) start up fine. I have also done a quick i686-gnu build (to see if static-start.S or init-first.c changes have broken something), and a statically linked hello world seems to still work as expected. As usual, the disclaimer about me not knowing what I'm doing: I don't! I especially am not at all familiar with AArch64, even less so than with x86_64. I could have done something incredibly stupid; please do review! That being said, these changes seem smaller and a lot less radical than the x86_64 port patchset; they're mostly adding things rather than reworking them, so there is less of a chance to break the x86 targets. Evidently, we've done enough rewrokings and portability fixes (notably, various 64-bit fixes) during the x86_64 port to make it easier to add new ports. This port itself continues this trend somewhat too, with init-first.c now finally becoming only sysdeps/mach/hurd -specific, and HTL gaining support for TLS_DTV_AT_TP. As I said in the previous letter on bug-hurd, the hardware hardening features (BTI, MTE, PAC) are currently "not really supported", but I do want to support them in the future. I'm extremely interested in getting feedback or suggestions about these. For example: what should our API for controlling PAC keys look like, should we just allow userland to read and write all the keys? Are there, for example, any gotchas with BTI that we need to be aware of? Is it possible to start using PAC after initial start-up (once /dev/random becomes available, so PAC keys can be initialized) — how would we do that without crashing on e.g. ret pointers that have not been encrypted? Finally, a couple of words about the page size. My plan is for userland to not assume any static value of page size, and always query it dynamically, unlike on x86, even though GNU Mach will likely be compiled with some fixed value of page size; my understanding is this is also how things are done on GNU/Linux. To that end, I've tried to reduce the reliance on <mach/vm_param.h> and on EXEC_PAGESIZE being defined. Currently, Mach headers still define *something* named PAGE_SIZE unconditionally, causing __mach_init () to pick it up and use it instead of querying the page size dynamically. We should make sure this does not happen (i.e. <mach/vm_param.h> should not define PAGE_SIZE on AArch64), this is just something I haven't figured out a nice way to fix yet. Sergey P.S. I have not forgotten about my other unmerged patch series! (Most importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I hope to find some time to hack on them, hopefully some time soon. Sergey Bugaev (23): hurd: Add some missing includes hurd: Declare _hurd_intr_rpc_msg* with protected visibility Allow glibc to be compiled without EXEC_PAGESIZE mach: Drop some unnecessary vm_param.h includes hurd: Disable Prefer_MAP_32BIT_EXEC on non-x86_64 for now mach: Drop SNARF_ARGS macro hurd: Pass the data pointer to _hurd_stack_setup explicitly hurd: Drop x86-specific assembly from init-first.c hurd: Make init-first.c no longer x86-specific hurd: Only init early static TLS if it's used to store stack or pointer guards hurd: Initializy _dl_pagesize early in static builds aarch64: Make cpu-features definitions not Linux-specific aarch64: Add dl-procinfo aarch64: Allow building without kernel support for BTI mach: Add a basic AArch64 port hurd: Add a basic AArch64 port hurd: Implement TLS on AArch64 hurd: Implement longjmp for AArch64 Add FPE_FLTIDO hurd: Add an AArch64 signal implementation htl: Implement some support for TLS_DTV_AT_TP htl: Add an AArch64 implementation hurd: Add expected aarch64-gnu abistlists bits/siginfo-consts.h | 4 +- elf/dl-support.c | 6 +- elf/rtld.c | 2 + htl/pt-create.c | 2 + hurd/hurdsig.c | 8 +- libio/libioP.h | 2 +- mach/Makefile | 1 + mach/lowlevellock.h | 1 + mach/setup-thread.c | 1 - .../sysv/linux => }/aarch64/cpu-features.h | 0 sysdeps/aarch64/dl-bti.c | 10 + sysdeps/aarch64/dl-procinfo.c | 59 + sysdeps/aarch64/dl-procinfo.h | 38 + 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/aarch64/htl/tcb-offsets.sym | 5 + .../sysv/linux => }/aarch64/libc-start.c | 0 sysdeps/htl/dl-thread_gscope_wait.c | 16 +- sysdeps/hurd/include/hurd.h | 1 + sysdeps/hurd/include/hurd/signal.h | 1 + sysdeps/mach/aarch64/bits/mach/param.h | 24 + sysdeps/mach/aarch64/cpu-features.c | 109 + sysdeps/mach/aarch64/sys/ucontext.h | 73 + sysdeps/mach/aarch64/sysdep.h | 45 + sysdeps/mach/aarch64/thread_state.h | 44 + sysdeps/mach/configure | 1 + sysdeps/mach/configure.ac | 1 + sysdeps/mach/hurd/aarch64/Implies | 3 + sysdeps/mach/hurd/aarch64/Makefile | 24 + sysdeps/mach/hurd/aarch64/____longjmp_chk.S | 173 ++ sysdeps/mach/hurd/aarch64/__longjmp.S | 150 ++ sysdeps/mach/hurd/aarch64/bits/sigcontext.h | 96 + .../mach/hurd/aarch64/dl-tls-initialized.c | 19 + sysdeps/mach/hurd/aarch64/exc2signal.c | 119 + sysdeps/mach/hurd/aarch64/htl/pt-machdep.c | 55 + sysdeps/mach/hurd/aarch64/htl/pt-setup.c | 80 + sysdeps/mach/hurd/aarch64/intr-msg.h | 123 + sysdeps/mach/hurd/aarch64/ld.abilist | 18 + .../mach/hurd/aarch64/libBrokenLocale.abilist | 1 + sysdeps/mach/hurd/aarch64/libanl.abilist | 4 + sysdeps/mach/hurd/aarch64/libc.abilist | 2123 +++++++++++++++++ .../hurd/aarch64/libc_malloc_debug.abilist | 26 + sysdeps/mach/hurd/aarch64/libdl.abilist | 0 sysdeps/mach/hurd/aarch64/libm.abilist | 1030 ++++++++ sysdeps/mach/hurd/aarch64/libmvec.abilist | 75 + sysdeps/mach/hurd/aarch64/libpthread.abilist | 165 ++ sysdeps/mach/hurd/aarch64/libresolv.abilist | 55 + sysdeps/mach/hurd/aarch64/librt.abilist | 33 + sysdeps/mach/hurd/aarch64/longjmp-ts.c | 50 + sysdeps/mach/hurd/aarch64/shlib-versions | 2 + sysdeps/mach/hurd/aarch64/signal-defines.sym | 10 + sysdeps/mach/hurd/aarch64/static-start.S | 52 + sysdeps/mach/hurd/aarch64/tls.h | 206 ++ sysdeps/mach/hurd/aarch64/trampoline.c | 327 +++ sysdeps/mach/hurd/aarch64/vm_param.h | 24 + sysdeps/mach/hurd/dl-sysdep.c | 3 +- sysdeps/mach/hurd/htl/pt-sysdep.c | 9 + sysdeps/mach/hurd/i386/static-start.S | 3 + sysdeps/mach/hurd/{x86 => }/init-first.c | 45 +- sysdeps/mach/hurd/mig-reply.c | 1 + sysdeps/mach/hurd/mmap.c | 2 +- sysdeps/mach/hurd/x86_64/static-start.S | 1 + sysdeps/mach/sysdep.h | 7 - sysdeps/mach/x86/sysdep.h | 14 - 66 files changed, 5639 insertions(+), 56 deletions(-) rename sysdeps/{unix/sysv/linux => }/aarch64/cpu-features.h (100%) create mode 100644 sysdeps/aarch64/dl-procinfo.c create mode 100644 sysdeps/aarch64/dl-procinfo.h create mode 100644 sysdeps/aarch64/htl/Makefile create mode 100644 sysdeps/aarch64/htl/bits/pthreadtypes-arch.h create mode 100644 sysdeps/aarch64/htl/machine-sp.h create mode 100644 sysdeps/aarch64/htl/pt-machdep.h create mode 100644 sysdeps/aarch64/htl/tcb-offsets.sym rename sysdeps/{unix/sysv/linux => }/aarch64/libc-start.c (100%) create mode 100644 sysdeps/mach/aarch64/bits/mach/param.h create mode 100644 sysdeps/mach/aarch64/cpu-features.c create mode 100644 sysdeps/mach/aarch64/sys/ucontext.h create mode 100644 sysdeps/mach/aarch64/sysdep.h create mode 100644 sysdeps/mach/aarch64/thread_state.h create mode 100644 sysdeps/mach/hurd/aarch64/Implies create mode 100644 sysdeps/mach/hurd/aarch64/Makefile create mode 100644 sysdeps/mach/hurd/aarch64/____longjmp_chk.S create mode 100644 sysdeps/mach/hurd/aarch64/__longjmp.S create mode 100644 sysdeps/mach/hurd/aarch64/bits/sigcontext.h create mode 100644 sysdeps/mach/hurd/aarch64/dl-tls-initialized.c create mode 100644 sysdeps/mach/hurd/aarch64/exc2signal.c create mode 100644 sysdeps/mach/hurd/aarch64/htl/pt-machdep.c create mode 100644 sysdeps/mach/hurd/aarch64/htl/pt-setup.c create mode 100644 sysdeps/mach/hurd/aarch64/intr-msg.h create mode 100644 sysdeps/mach/hurd/aarch64/ld.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libBrokenLocale.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libanl.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libc.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libc_malloc_debug.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libdl.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libm.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libmvec.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libpthread.abilist create mode 100644 sysdeps/mach/hurd/aarch64/libresolv.abilist create mode 100644 sysdeps/mach/hurd/aarch64/librt.abilist create mode 100644 sysdeps/mach/hurd/aarch64/longjmp-ts.c create mode 100644 sysdeps/mach/hurd/aarch64/shlib-versions create mode 100644 sysdeps/mach/hurd/aarch64/signal-defines.sym create mode 100644 sysdeps/mach/hurd/aarch64/static-start.S create mode 100644 sysdeps/mach/hurd/aarch64/tls.h create mode 100644 sysdeps/mach/hurd/aarch64/trampoline.c create mode 100644 sysdeps/mach/hurd/aarch64/vm_param.h rename sysdeps/mach/hurd/{x86 => }/init-first.c (87%)