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,
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
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 er
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-M
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
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
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.
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
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 ch
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 cu
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 de
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
12 matches
Mail list logo
