Re: Hurd Christmas Party Saturday January 20th

[jbranso]

Hey friends!

So it turns out, that the best time for this belated new Years party will be on 
Saturday January 20 at 3pm UTC.  I believe that the best way to virtually meet 
will be through my jitsi account that I have with the FSF.  It sounds like 
Sergey will be announcing something super cool, so you definitely want to stick 
around for that.  If you have any awesome things that you want to show off, 
then please let me know about it.  Shall I go ahead and post this event to 
reddit and the like?

Thanks,

Joshua

Re: aarch64-gnu (and Happy New Year!)

[Samuel Thibault]

Sergey Bugaev, le mar. 02 janv. 2024 00:04:24 +0300, a ecrit:
> I wouldn't be surprised if pfinet contains known old CVEs, for one
> thing.

On the long run we want to just fix any last remaining issues with
lwip, and use that rather than continuing to spend time on the old
unmaintained linux stack of pfinet.

Samuel

Re: aarch64-gnu (and Happy New Year!)

[Sergey Bugaev]

On Mon, Jan 1, 2024 at 10:21 PM Luca  wrote:
> > MIG seems to just work (thanks to all the Flávio's work!). I'm using
> > the same message ABI as on x86_64, and haven't seen any issues so far
> > — neither compiler errors / failed static assertions (about struct
> > sizes and such), nor hardware errors from misaligned accesses.
>
> Good to hear! so if I understand it correctly you tested it on aarch64
> GNU/Linux?

(Non-GNU) Linux on aarch64, yes. More specifically, this is a phone
running postmarketOS. I've run gdbserver on it, and connected GDB to
it over SSH.

> >> I actually have an armv8 server that would be handy for some
> >> development, so I might be able to help with something in the future.
> >
> > Sounds great! (But you should also be able to use qemu, no?)
>
> You can emulate aarch64 from an amd64 machine, but it's not very
> efficient. Also, I would realay like to run GNU/Hurd natively :)

Eventually, sure; my point is you don't even need real hardware for
starting to hack on aarch64 gnumach.

> Do you mean Pointer Authentication Code? That seems quite a new feature,
> so maybe not fundamental to have a first working kernel, but anyway I
> don't see issues in having arch-specific data in tasks.

Yes. Certainly not fundamental for an initial port; none of these
hardening features are.

But it also would be very nice to have support for eventually. Since
the Hurd's code has seen a lot less scrutiny than that of Linux, it's
likely much easier to find vulnerabilities caused by memory unsafety —
I wouldn't be surprised if pfinet contains known old CVEs, for one
thing. So hardening is even more relevant for us, if we want people to
consider running GNU/Hurd on network-facing servers more seriously.

Sergey

Re: aarch64-gnu (and Happy New Year!)

[Samuel Thibault]

Hello,

Sergey Bugaev, le lun. 01 janv. 2024 16:51:20 +0300, a ecrit:
> Do we have all the mechanisms required for userland to poke at
> specific addresses in memory (to replace I/O ports)? — I believe we
> do, but I haven't looked closely.

It's the mem mach device.

> Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64?

pfinet is probably very easy.
In-Mach drivers, I wouldn't hope so at all (arm64 was probably not even
a thing at the time). Netdde, perhaps, but I'd rather bet on rumpkernel.

Samuel

Re: aarch64-gnu (and Happy New Year!)

[Luca]

Il 01/01/24 14:51, Sergey Bugaev ha scritto:

On Mon, Jan 1, 2024 at 4:02 PM Luca  wrote:

Hi Sergey,


Hi Luca,


Really great work! To work on gnumach we just need MIG and any armv8
compiler (also targeting GNU/Linux is fine), and it seems MIG works fine
without adjustments? Maybe there could be some issues once it's run
somewhere, e.g. alignment issues.


Well, I have the aarch64-gnu toolchain here, please see the binutils &
GCC patches that I posted. But yeah, any aarch64-targeting compiler
should work for gnumach, including aarch64-linux-gnu or just a generic
embedded aarch64 target.

MIG seems to just work (thanks to all the Flávio's work!). I'm using
the same message ABI as on x86_64, and haven't seen any issues so far
— neither compiler errors / failed static assertions (about struct
sizes and such), nor hardware errors from misaligned accesses.


Good to hear! so if I understand it correctly you tested it on aarch64 
GNU/Linux?




Once I post the preliminary gnumach patches, you should be able to
build a complete binutils + GCC + MIG aarch64-gnu toolchain.


Another issue with ARM in general is that the hardware support is much
less streamlined than x86, although with v8 there should be some
alignment on basic stuff like IRQ and UEFI.


So I've heard, yeah. But yeah I've also heard that newer chips support
UEFI, and from UEFI it should be possible to boot GRUB and from there
gnumach, so maybe the boot process is not as much of a problem as it
was, and we could avoid separate per-board builds of gnumach.


Starting the kernel itself will probably not a problem, thanks to GRUB, 
but it shouldn't be too hard to add support for U-Boot either if needed.


I think more issues might come out setting up the various pieces of the 
system. For example, some chips have heterogeneous cores, (e.g.mine has 
two A72 cores and four A53 cores) so SMP will be more complicated.


Also, about the serial console, it might be useful at some point to use 
a driver from userspace, if we can reuse some drivers from netbsd or 
linux, to avoid embedding all of them in gnumach.



But as always, I have no idea what I'm talking about.


Probably even the serial
console needs a platform-specific driver (I'm not sure, I'm more
familiar with older and more embedded variants like Cortex-M)

To bootstrap gnumach the first thing we'd need would probably be the
console, setting up the virtual memory, then thread states, context
switch, irqs and userspace entry points (list by no means exhaustive).

I actually have an armv8 server that would be handy for some
development, so I might be able to help with something in the future.


Sounds great! (But you should also be able to use qemu, no?)


You can emulate aarch64 from an amd64 machine, but it's not very 
efficient. Also, I would realay like to run GNU/Hurd natively :)




Even before you write any code, it would be great if you helped review
my gnumach patches (e.g. aarch64_thread_state & the arm/aarch64
exceptions).


sure, but I'll have to get a bit more familiar with the aarch64 details 
first.



Also, there is a bunch of design work to do.

Will/can AArch64 use the same mechanism for letting userland handle
interrupts? Do we have all the mechanisms required for userland to
poke at specific addresses in memory (to replace I/O ports)? — I
believe we do, but I haven't looked closely.


AFAIK there are no I/O ports in ARM, the usual way to configure things 
is with memory-mapped registers, so this might become even easier. About 
IRQs, probably it needs to be arch-specific anyway.



What should the API for manipulating PAC keys look like? I kind of
want it to be just another flavor of thread state, but then it is
really supposed to be per-trask, not per-thread, and maybe adding some
aarch64-specific RPCs to read and write the PAC keys in
mach_aarch64.defs is the right way. But also AFAICS Mach currently has
no notion of per-task arch-specific data (unlike for threads, and
other than the VM map), so it'd be interesting to add one — could it
be useful for something else?


Do you mean Pointer Authentication Code? That seems quite a new feature, 
so maybe not fundamental to have a first working kernel, but anyway I 
don't see issues in having arch-specific data in tasks.



What are the debugging facilities available on ARM / AArch64? Should
we expose them as more flavors of thread state, or...? What would GDB
need?


For gnumach, it might be easier to debug on real hw than x86 if we can 
use openocd as gdbserver (but JTAG lines are not always reachable).


For user space tasks I don't know.



Should gnumach accept tagged addresses (like PR_SET_TAGGED_ADDR_CTRL on Linux)?


It could, but also it doesn't seem mandatory, so I would start without it.


Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64?


I think nowadays LKL would be a better target, unless there are drivers 
in netdde used also on aarch64. however AFAIK LKL doesn't support 
aarch64, and 

Re: aarch64-gnu (and Happy New Year!)

[Abhiseck Paira]

Wow, it's great to hear!  You really surprised me there.

> P.S. Believe it or not, this is not the announcement that I was going
> to make at Joshua's Christmas party; I only started hacking on this
> later, after that email exchange. That other thing is still to be
> announced :)

I'll be looking forward to your next announcement!

-- 
Abhiseck Paira (https://paira.in)
"Over himself, over his own body and mind, the individual is sovereign."

Re: aarch64-gnu (and Happy New Year!)

[Sergey Bugaev]

On Mon, Jan 1, 2024 at 4:02 PM Luca  wrote:
> Hi Sergey,

Hi Luca,

> Really great work! To work on gnumach we just need MIG and any armv8
> compiler (also targeting GNU/Linux is fine), and it seems MIG works fine
> without adjustments? Maybe there could be some issues once it's run
> somewhere, e.g. alignment issues.

Well, I have the aarch64-gnu toolchain here, please see the binutils &
GCC patches that I posted. But yeah, any aarch64-targeting compiler
should work for gnumach, including aarch64-linux-gnu or just a generic
embedded aarch64 target.

MIG seems to just work (thanks to all the Flávio's work!). I'm using
the same message ABI as on x86_64, and haven't seen any issues so far
— neither compiler errors / failed static assertions (about struct
sizes and such), nor hardware errors from misaligned accesses.

Once I post the preliminary gnumach patches, you should be able to
build a complete binutils + GCC + MIG aarch64-gnu toolchain.

> Another issue with ARM in general is that the hardware support is much
> less streamlined than x86, although with v8 there should be some
> alignment on basic stuff like IRQ and UEFI.

So I've heard, yeah. But yeah I've also heard that newer chips support
UEFI, and from UEFI it should be possible to boot GRUB and from there
gnumach, so maybe the boot process is not as much of a problem as it
was, and we could avoid separate per-board builds of gnumach.

But as always, I have no idea what I'm talking about.

> Probably even the serial
> console needs a platform-specific driver (I'm not sure, I'm more
> familiar with older and more embedded variants like Cortex-M)
>
> To bootstrap gnumach the first thing we'd need would probably be the
> console, setting up the virtual memory, then thread states, context
> switch, irqs and userspace entry points (list by no means exhaustive).
>
> I actually have an armv8 server that would be handy for some
> development, so I might be able to help with something in the future.

Sounds great! (But you should also be able to use qemu, no?)

Even before you write any code, it would be great if you helped review
my gnumach patches (e.g. aarch64_thread_state & the arm/aarch64
exceptions).

Also, there is a bunch of design work to do.

Will/can AArch64 use the same mechanism for letting userland handle
interrupts? Do we have all the mechanisms required for userland to
poke at specific addresses in memory (to replace I/O ports)? — I
believe we do, but I haven't looked closely.

What should the API for manipulating PAC keys look like? I kind of
want it to be just another flavor of thread state, but then it is
really supposed to be per-trask, not per-thread, and maybe adding some
aarch64-specific RPCs to read and write the PAC keys in
mach_aarch64.defs is the right way. But also AFAICS Mach currently has
no notion of per-task arch-specific data (unlike for threads, and
other than the VM map), so it'd be interesting to add one — could it
be useful for something else?

What are the debugging facilities available on ARM / AArch64? Should
we expose them as more flavors of thread state, or...? What would GDB
need?

Should gnumach accept tagged addresses (like PR_SET_TAGGED_ADDR_CTRL on Linux)?

Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64?

Sergey

Re: aarch64-gnu (and Happy New Year!)

[Luca]

Hi Sergey,

Il 31/12/23 20:53, Sergey Bugaev ha scritto:

Hello, and happy holidays!

Every now and then, I hear someone mention potential ports of gnumach
to new architectures. I think I have heard RISC-V and (64-bit?) ARM
mentioned somewhere recently as potential new port targets. Being
involved in the x86_64 port last spring was a really fun and
interesting experience, and I learned a lot; so I, for one, have
always thought doing more ports would be a great idea, and that I
would be glad to be a part of such an effort again.

Among the architectures, AArch64 and RISC-V indeed seem most
attractive (not that I know much about either). Among those two,
RISC-V is certainly newer and more exciting, but Aarch64 is certainly
more widespread and established. (Wouldn't it be super cool if we
could run GNU/Hurd everywhere from tiny ARM boards, to Raspberry Pi's,
to common smartphones, to, now, ARM-based laptops desktops?) Also I
have had some experience with ARM in the past, so I knew a tiny bit of
ARM assembly.

So I thought, what would it take to port the Hurd to AArch64, a
completely non-x86 architecture, one that I knew very little about?
There is no AArch64 gnumach (that I know of) yet, but I could try to
hack on glibc even without one, I'd only need some headers, right?
There's also no compiler toolchain, but those patches to add the
x86_64-gnu target looked pretty understandable, so — how hard could it
be?

Well, I did more than think about it :)

I read up on AArch64 registers / assembly / architecture / calling
convention, added the aarch64-gnu target to binutils and GCC, added
basic versions of mach/aarch64/ headers to gnumach (but no actual
code), and made a mostly complete port of glibc. I haven't spent much
effort on Hurd proper, but I have tried running the build, and the
core Hurd servers (ext2fs, proc, exec, auth) do get built.

I will be posting the patches soon. For now, here's just a little teaser:

glibc/build $ file libc.so elf/ld.so
libc.so: ELF 64-bit LSB shared object, ARM aarch64, version 1
(GNU/Linux), dynamically linked, interpreter /lib/ld-aarch64.so.1, for
GNU/Hurd 0.0.0, with debug_info, not stripped
elf/ld.so: ELF 64-bit LSB shared object, ARM aarch64, version 1
(SYSV), dynamically linked, with debug_info, not stripped

hurd/build $ file ext2fs/ext2fs.static proc/proc
ext2fs/ext2fs.static: ELF 64-bit LSB executable, ARM aarch64, version
1 (GNU/Linux), statically linked, for GNU/Hurd 0.0.0, with debug_info,
not stripped
proc/proc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-aarch64.so.1, for GNU/Hurd
0.0.0, with debug_info, not stripped

glibc/build $ aarch64-gnu-objdump --disassemble=__mig_get_reply_port libc.so
libc.so: file format elf64-littleaarch64
Disassembly of section .plt:
Disassembly of section .text:
0002b8e0 <__mig_get_reply_port>:
2b8e0: a9be7bfd stp x29, x30, [sp, #-32]!
2b8e4: 910003fd mov x29, sp
2b8e8: f9000bf3 str x19, [sp, #16]
2b8ec: d53bd053 mrs x19, tpidr_el0
2b8f0: b85f8260 ldur w0, [x19, #-8]
2b8f4: 3480 cbz w0, 2b904 <__mig_get_reply_port+0x24>
2b8f8: f9400bf3 ldr x19, [sp, #16]
2b8fc: a8c27bfd ldp x29, x30, [sp], #32
2b900: d65f03c0 ret
2b904: 97fffbef bl 2a8c0 <__mach_reply_port>
2b908: b81f8260 stur w0, [x19, #-8]
2b90c: f9400bf3 ldr x19, [sp, #16]
2b910: a8c27bfd ldp x29, x30, [sp], #32
2b914: d65f03c0 ret

So it compiles and links, but does it work? — well, we can't know
that, not until someone ports gnumach, right?

Well actually we can :) I've done the same thing as last time, when
working on the x86_64 port: run a statically linked hello world
executable on Linux, under GDB, carefully skipping over and emulating
syscalls and RPCs. This did uncover a number of bugs, both in my port
of glibc and in how the toolchain was set up (the first issue was that
static-init.S was not even getting linked in, the second issue was
that static-init.S was crashing even prior to the _hurd_stack_setup
call, and so on). But, I fixed all of those, and got the test
executable working! — as in, successfully running all the glibc
initialization (no small feat; this includes TLS setup, hwcaps /
cpu-features, and ifuncs), reaching main (), successfully doing puts
(), and shutting down. So it totally works, and is only missing an
AArch64 gnumach to run on.

The really unexpected part is how easy this actually was: it took me
like 3 days from "ok, guess I'm doing this, let's add a new target to
binutils and gcc" to glibc building successfully, and a couple more
days to get hello world to work (single-stepping under GDB is just
that time-consuming). Either I'm getting good at this..., or (perhaps
more realistically) maybe it was just easy all along, and it was my
inexperience with glibc internals that slowed me down the last time.
Also, we have worked out a lot of 64-bit issues with the x86_64 port,
so this is something I didn't have to deal with this tim

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

[Sergey Bugaev]

Coupled with a corresponding binutils patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.

Signed-off-by: Sergey Bugaev 
---
 gcc/config.gcc   |  6 +++
 gcc/config/aarch64/aarch64-gnu.h | 68 
 2 files changed, 74 insertions(+)
 create mode 100644 gcc/config/aarch64/aarch64-gnu.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index f0676c830..d8dd127ad 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1263,6 +1263,12 @@ aarch64*-*-linux*)
done
TM_MULTILIB_CONFIG=`echo $TM_MULTILIB_CONFIG | sed 's/^,//'`
;;
+aarch64*-*-gnu*)
+tm_file="${tm_file} elfos.h gnu-user.h gnu.h glibc-stdint.h"
+tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-errata.h 
aarch64/aarch64-gnu.h"
+tmake_file="${tmake_file} aarch64/t-aarch64"
+tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
+   ;;
 aarch64*-wrs-vxworks*)
 tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
 tm_file="${tm_file} vx-common.h vxworks.h aarch64/aarch64-vxworks.h"
diff --git a/gcc/config/aarch64/aarch64-gnu.h b/gcc/config/aarch64/aarch64-gnu.h
new file mode 100644
index 0..ee5494034
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-gnu.h
@@ -0,0 +1,68 @@
+/* Definitions for AArch64 running GNU/Hurd.
+   Copyright (C) 2009-2024 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef GCC_AARCH64_GNU_H
+#define GCC_AARCH64_GNU_H
+
+#define GNU_USER_DYNAMIC_LINKER 
"/lib/ld-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1"
+
+#define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
+#define GNU_TARGET_LINK_SPEC  "%{h*}   \
+   %{static:-Bstatic}  \
+   %{shared:-shared}   \
+   %{symbolic:-Bsymbolic}  \
+   %{!static:%{!static-pie:\
+ %{rdynamic:-export-dynamic}   \
+ %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
+   %{static-pie:-Bstatic -pie --no-dynamic-linker -z text} \
+   -X  \
+   %{mbig-endian:-EB} %{mlittle-endian:-EL} \
+   -maarch64gnu%{mabi=ilp32:32}%{mbig-endian:b}"
+
+
+#define LINK_SPEC GNU_TARGET_LINK_SPEC AARCH64_ERRATA_LINK_SPEC
+
+#define GNU_USER_TARGET_MATHFILE_SPEC \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}"
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC   \
+  GNU_USER_TARGET_MATHFILE_SPEC " " \
+  GNU_USER_TARGET_ENDFILE_SPEC
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+   GNU_USER_TARGET_OS_CPP_BUILTINS();  \
+}  \
+  while (0)
+
+#define TARGET_ASM_FILE_END aarch64_file_end_indicate_exec_stack
+
+/* Uninitialized common symbols in non-PIE executables, even with
+   strong definitions in dependent shared libraries, will resolve
+   to COPY relocated symbol in the executable.  See PR65780.  */
+#undef TARGET_BINDS_LOCAL_P
+#define TARGET_BINDS_LOCAL_P default_binds_local_p_2
+
+/* Define this to be nonzero if static stack checking is supported.  */
+#define STACK_CHECK_STATIC_BUILTIN 1
+
+#endif  /* GCC_AARCH64_GNU_H */
-- 
2.43.0

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

[Sergey Bugaev]

Since it's not i386-specific; this makes it possible to reuse it for other
architectures.

Also, add a warning for the case gnu.h is specified before gnu-user.h, which
would cause gnu-user's version of the spec to override gnu's, and not the other
way around as it's intended. The i?86-gnu target currently specifies them in
the right order, but it's easy to accidentally put them in a wrong order.

Signed-off-by: Sergey Bugaev 
---
 gcc/config/gnu.h  | 16 
 gcc/config/i386/gnu.h | 11 ---
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/gcc/config/gnu.h b/gcc/config/gnu.h
index 97baea939..89904cd9b 100644
--- a/gcc/config/gnu.h
+++ b/gcc/config/gnu.h
@@ -31,3 +31,19 @@ along with GCC.  If not, see .
builtin_assert ("system=unix"); \
builtin_assert ("system=posix");\
 } while (0)
+
+
+#ifndef GNU_USER_TARGET_STARTFILE_SPEC
+# warning This file should be included after gnu-user.h, to override its 
STARTFILE_SPEC
+#endif
+
+#undef STARTFILE_SPEC
+#if defined HAVE_LD_PIE
+#define STARTFILE_SPEC \
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
+#else
+#define STARTFILE_SPEC \
+  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
+#endif
diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index e776144f9..60244bfc8 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -24,17 +24,6 @@ along with GCC.  If not, see .
 #undef GNU_USER_DYNAMIC_LINKER
 #define GNU_USER_DYNAMIC_LINKER "/lib/ld.so"
 
-#undef STARTFILE_SPEC
-#if defined HAVE_LD_PIE
-#define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;"
 PIE_SPEC ":Scrt1.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|static-pie|" PIE_SPEC 
":crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
-
 #ifdef TARGET_LIBC_PROVIDES_SSP
 
 /* i386 glibc provides __stack_chk_guard in %gs:0x14.  */
-- 
2.43.0

[PATCH gcc 3/3] libgcc: Add basic support for aarch64-gnu (GNU/Hurd on AArch64)

[Sergey Bugaev]

There is currently no unwinding implementation.

Signed-off-by: Sergey Bugaev 
---
 libgcc/config.host  |  9 +++
 libgcc/config/aarch64/gnu-unwind.h  | 36 +
 libgcc/config/aarch64/heap-trampoline.c |  4 +--
 3 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 libgcc/config/aarch64/gnu-unwind.h

diff --git a/libgcc/config.host b/libgcc/config.host
index 54d06978a..c5b4df2c5 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -448,6 +448,15 @@ aarch64*-*-linux*)
tmake_file="${tmake_file} t-dfprules"
tmake_file="${tmake_file} ${cpu_type}/t-heap-trampoline"
;;
+aarch64*-*-gnu*)
+   extra_parts="$extra_parts crtfastmath.o"
+   md_unwind_header=aarch64/gnu-unwind.h
+   tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
+   tmake_file="${tmake_file} ${cpu_type}/t-lse t-slibgcc-libgcc"
+   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
+   tmake_file="${tmake_file} t-dfprules"
+   tmake_file="${tmake_file} ${cpu_type}/t-heap-trampoline"
+   ;;
 aarch64*-*-vxworks7*)
extra_parts="$extra_parts crtfastmath.o"
md_unwind_header=aarch64/aarch64-unwind.h
diff --git a/libgcc/config/aarch64/gnu-unwind.h 
b/libgcc/config/aarch64/gnu-unwind.h
new file mode 100644
index 0..d9e485a18
--- /dev/null
+++ b/libgcc/config/aarch64/gnu-unwind.h
@@ -0,0 +1,36 @@
+/* DWARF2 EH unwinding support for GNU Hurd: aarch64.
+   Copyright (C) 2020-2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* Always include AArch64 unwinder header file.  */
+#include "config/aarch64/aarch64-unwind.h"
+
+#ifndef inhibit_libc
+
+#include 
+
+/*
+ * TODO: support for aarch64 needs to be implemented.
+ */
+
+#endif /* ifndef inhibit_libc */
diff --git a/libgcc/config/aarch64/heap-trampoline.c 
b/libgcc/config/aarch64/heap-trampoline.c
index f22233987..6565584c7 100644
--- a/libgcc/config/aarch64/heap-trampoline.c
+++ b/libgcc/config/aarch64/heap-trampoline.c
@@ -23,7 +23,7 @@ void *allocate_trampoline_page (void);
 void __builtin_nested_func_ptr_created (void *chain, void *func, void **dst);
 void __builtin_nested_func_ptr_deleted (void);
 
-#if defined(__gnu_linux__)
+#if defined(__gnu_linux__) || defined(__gnu_hurd__)
 static const uint32_t aarch64_trampoline_insns[] = {
   0xd503245f, /* hint34 */
   0x58b1, /* ldr x17, .+20 */
@@ -76,7 +76,7 @@ allocate_trampoline_page (void)
 {
   void *page;
 
-#if defined(__gnu_linux__)
+#if defined(__gnu_linux__) || defined(__gnu_hurd__)
   page = mmap (0, getpagesize (), PROT_WRITE | PROT_EXEC,
   MAP_ANON | MAP_PRIVATE, 0, 0);
 #elif __APPLE__
-- 
2.43.0

[PATCH binutils] Add support for the aarch64-gnu target (GNU/Hurd on AArch64)

[Sergey Bugaev]

Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or
aarch64-unknown-gnu.

The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh,
or to aarch64linux.sh with Linux-specific logic removed; and mainly different
from the generic aarch64elf.sh in that it does not set EMBEDDED=yes.

Coupled with a corresponding GCC patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.

Signed-off-by: Sergey Bugaev 
---
 bfd/config.bfd  |  2 +-
 gas/configure.tgt   |  1 +
 ld/configure.tgt|  5 +
 ld/emulparams/aarch64gnu.sh | 37 +
 4 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 ld/emulparams/aarch64gnu.sh

diff --git a/bfd/config.bfd b/bfd/config.bfd
index 4106924e..9f3d4d46 100644
--- a/bfd/config.bfd
+++ b/bfd/config.bfd
@@ -284,7 +284,7 @@ case "${targ}" in
 targ_selvecs="aarch64_elf64_be_vec aarch64_elf32_le_vec 
aarch64_elf32_be_vec arm_elf32_le_vec arm_elf32_be_vec"
 want64=true
 ;;
-  aarch64-*-linux* | aarch64-*-netbsd* | aarch64-*-nto*)
+  aarch64-*-linux* | aarch64-*-netbsd* | aarch64-*-nto* | aarch64-*-gnu*)
 targ_defvec=aarch64_elf64_le_vec
 targ_selvecs="aarch64_elf64_be_vec aarch64_elf32_le_vec 
aarch64_elf32_be_vec arm_elf32_le_vec arm_elf32_be_vec aarch64_pei_le_vec 
aarch64_pe_le_vec"
 want64=true
diff --git a/gas/configure.tgt b/gas/configure.tgt
index 3a582ef4..15c1ed3d 100644
--- a/gas/configure.tgt
+++ b/gas/configure.tgt
@@ -134,6 +134,7 @@ case ${generic_target} in
 case ${cpu}-${os} in
   aarch64*-linux-gnu_ilp32)arch=aarch64:32 ;;
 esac ;;
+  aarch64*-*-gnu*) fmt=elf em=gnu ;;
   aarch64*-*-netbsd*)  fmt=elf em=nbsd;;
   aarch64*-*-nto*) fmt=elf;;
   aarch64*-*-openbsd*) fmt=elf;;
diff --git a/ld/configure.tgt b/ld/configure.tgt
index afd43032..211a2dee 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -116,6 +116,11 @@ aarch64-*-linux*)  targ_emul=aarch64linux
targ_extra_libpath="aarch64linuxb aarch64linux32 
aarch64linux32b armelfb_linux_eabi armelf_linux_eabi"
targ_extra_emuls="aarch64elf aarch64elf32 aarch64elf32b 
aarch64elfb armelf armelfb $targ_extra_libpath"
;;
+# This has to come after aarch64-*-linux* for aarch64-*-linux-gnu to hit the 
Linux branch.
+aarch64-*-gnu*)
+   targ_emul=aarch64gnu
+   targ_extra_emuls="aarch64elf aarch64elfb armelf armelfb"
+   ;;
 aarch64-*-haiku*)  targ_emul=aarch64haiku
targ_extra_emuls="aarch64elf aarch64elf32 aarch64elf32b 
aarch64elfb armelf armelfb armelf_haiku $targ_extra_libpath"
;;
diff --git a/ld/emulparams/aarch64gnu.sh b/ld/emulparams/aarch64gnu.sh
new file mode 100644
index ..0bcab7a4
--- /dev/null
+++ b/ld/emulparams/aarch64gnu.sh
@@ -0,0 +1,37 @@
+ARCH=aarch64
+MACHINE=
+NOP=0x1f2003d5
+
+SCRIPT_NAME=elf
+ELFSIZE=64
+OUTPUT_FORMAT="elf64-littleaarch64"
+BIG_OUTPUT_FORMAT="elf64-bigaarch64"
+LITTLE_OUTPUT_FORMAT="elf64-littleaarch64"
+NO_REL_RELOCS=yes
+
+TEMPLATE_NAME=elf
+EXTRA_EM_FILE=aarch64elf
+
+GENERATE_SHLIB_SCRIPT=yes
+GENERATE_PIE_SCRIPT=yes
+
+MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"
+COMMONPAGESIZE="CONSTANT (COMMONPAGESIZE)"
+SEPARATE_GOTPLT=24
+IREL_IN_PLT=
+
+TEXT_START_ADDR=0x40
+
+DATA_START_SYMBOLS='PROVIDE (__data_start = .);';
+
+# AArch64 does not support .s* sections.
+NO_SMALL_DATA=yes
+
+OTHER_BSS_SYMBOLS="${CREATE_SHLIB+PROVIDE (}__bss_start__ = 
.${CREATE_SHLIB+)};"
+OTHER_BSS_END_SYMBOLS="${CREATE_SHLIB+PROVIDE (}_bss_end__ = 
.${CREATE_SHLIB+)}; ${CREATE_SHLIB+PROVIDE (}__bss_end__ = .${CREATE_SHLIB+)};"
+OTHER_END_SYMBOLS="${CREATE_SHLIB+PROVIDE (}__end__ = .${CREATE_SHLIB+)};"
+
+OTHER_SECTIONS='.note.gnu.arm.ident 0 : { KEEP (*(.note.gnu.arm.ident)) }'
+ATTRS_SECTIONS='.ARM.attributes 0 : { KEEP (*(.ARM.attributes)) KEEP 
(*(.gnu.attributes)) }'
+# Ensure each PLT entry is aligned to a cache line.
+PLT=".plt  ${RELOCATING-0} : ALIGN(16) { 
*(.plt)${RELOCATING+${IREL_IN_PLT+ *(.iplt)}} }"
-- 
2.43.0