> On Jan 3, 2024, at 21:14, Sergey Bugaev <buga...@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
