On Tue, Feb 28, 2023 at 10:18 AM Samuel Thibault
wrote:
>
> Sergey Bugaev, le mar. 28 févr. 2023 09:39:40 +0300, a ecrit:
> > > + : \
> > > + : "c" (regaddr), "a" (low), "d" (high) \
> > > + : "memory"
Sergey Bugaev, le mar. 28 févr. 2023 09:39:40 +0300, a ecrit:
> > + : \
> > + : "c" (regaddr), "a" (low), "d" (high) \
> > + : "memory" \
> > +);
> > +}
>
> Why "memory" here? C
> But then glibc does not actually use mach/syscall_sw.h, it has its own
> syscall impl
Uh, actually looks like it does both. Fun! :)
Sergey
On Mon, Feb 27, 2023 at 11:46 PM Luca Dariz wrote:
>
> While theoretically we could still use the same call gate as for
> 32-bit userspace, it doesn't seem very common, and gcc seems to not
> encode properly the instruction. Instead we use syscall/sysret as
> other kernels (e.g. XNU,Linux). This v
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 22 févr. 2023 00:19:32 +0300, a ecrit:
> Signed-off-by: Sergey Bugaev
> ---
> sysdeps/x86_64/htl/bits/pthreadtypes-arch.h | 36 +
> 1 file changed, 36 insertions(+)
> create mode 100644 sysdeps/x86_64/htl/bits/pthreadtyp
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 22 févr. 2023 00:19:31 +0300, a ecrit:
> Signed-off-by: Sergey Bugaev
> ---
> sysdeps/mach/hurd/x86/init-first.c | 14 +-
> sysdeps/mach/hurd/x86_64/tls.h | 215 +
> 2 files changed, 228 insertions(+), 1 dele
Applied, thanks!
Flavio Cruz, le dim. 19 févr. 2023 18:06:51 -0500, a ecrit:
> We introduce both a user alignment and a kernel alignment. These are
> separate requirements since for 64 bit with a 32 bit kernel we need to
> ensure the kernel can consume messages that are 8-byte aligned. This
> chan
Applied, thanks!
Flavio Cruz, le dim. 19 févr. 2023 18:11:05 -0500, a ecrit:
> By using uintptr_t, we ensure that all 64 bit stubs are free of
> undefined behavior since we support up to 8-byte alignment. This works
> fine given that Mig will type check types that have higher alignment
> requireme
Applied, thanks!
Flavio Cruz, le ven. 17 févr. 2023 00:51:04 -0500, a ecrit:
> This was a miss in the previous patch given that mach_msg_type_long_t is
> 12 bytes long so won't neatly align to 8 bytes.
> ---
> utils.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mar. 14 févr. 2023 20:37:22 +0300, a ecrit:
> This is for future-proofing. On i386, it is 4-byte aligned anyway, but
> on x86_64, we want it 8-byte aligned, not 4-byte aligned.
>
> Signed-off-by: Sergey Bugaev
> ---
> .../hurd/htl/bits/types/str
Luca Dariz, le lun. 27 févr. 2023 21:44:56 +0100, a ecrit:
> This enables simple user-space programs compiled for x86_64. Regular
> syscalls should work, RPCs are not yet properly working:
> * the commit "fix port name copyin" is just to make simple rpc work
> * To test the syscalls I patched mig t
Luca Dariz, le lun. 27 févr. 2023 21:45:01 +0100, a ecrit:
> diff --git a/i386/i386/ldt.h b/i386/i386/ldt.h
> index b15f11a5..4490f99f 100644
> --- a/i386/i386/ldt.h
> +++ b/i386/i386/ldt.h
> @@ -45,9 +45,14 @@
> #define USER_SCALL 0x07/* system call gate */
> #ifdef __x86_6
Applied, thanks!
Luca Dariz, le lun. 27 févr. 2023 21:45:00 +0100, a ecrit:
> * i386/i386/locore.h: user vm_offset_t in the recovery_table
> * x86_64/locore.S: fix RECOVERY() location and keep user regs in %rbx,
> as it seems the convention. This only applies to 32-bit userspace.
> ---
> i386/i
Applied, thanks!
Luca Dariz, le lun. 27 févr. 2023 21:44:59 +0100, a ecrit:
> * x86_64/copy_user.c: in mach_msg_user_header_t there are some holes
> that need to be cleared, to adapt to the different layout of
> mach_msg_header_t.
> ---
> x86_64/copy_user.c | 2 ++
> 1 file changed, 2 inserti
Applied, thanks!
Luca Dariz, le lun. 27 févr. 2023 21:44:58 +0100, a ecrit:
> * x86_64/copy_user.c: fix copyin/out, we already have a pointer to
> user/kernel buffers
> ---
> x86_64/copy_user.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/x86_64/copy_user.c b/x8
Applied, thanks!
Luca Dariz, le lun. 27 févr. 2023 21:44:57 +0100, a ecrit:
> * i386/intel/pmap.c: remove #error and allow compilation, keeping a
> reminder to fix the pmap module.
> ---
> i386/intel/pmap.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/i386/int
* i386/intel/pmap.c: remove #error and allow compilation, keeping a
reminder to fix the pmap module.
---
i386/intel/pmap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c
index 302a60cb..40f672b5 100644
--- a/i386/intel/pmap.c
+++ b
* x86_64/copy_user.c: fix copyin/out, we already have a pointer to
user/kernel buffers
---
x86_64/copy_user.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/x86_64/copy_user.c b/x86_64/copy_user.c
index dd9fe2d7..86d23525 100644
--- a/x86_64/copy_user.c
+++ b/x86_64/copy
While theoretically we could still use the same call gate as for
32-bit userspace, it doesn't seem very common, and gcc seems to not
encode properly the instruction. Instead we use syscall/sysret as
other kernels (e.g. XNU,Linux). This version still has some
limitations, but should be enough to sta
This enables simple user-space programs compiled for x86_64. Regular
syscalls should work, RPCs are not yet properly working:
* the commit "fix port name copyin" is just to make simple rpc work
* To test the syscalls I patched mig to not add the _Static_assert()
statements, otherwise gnumach fail
* i386/i386/locore.h: user vm_offset_t in the recovery_table
* x86_64/locore.S: fix RECOVERY() location and keep user regs in %rbx,
as it seems the convention. This only applies to 32-bit userspace.
---
i386/i386/locore.h | 4 ++--
x86_64/locore.S| 20 ++--
2 files changed,
* x86_64/copy_user.c: in mach_msg_user_header_t there are some holes
that need to be cleared, to adapt to the different layout of
mach_msg_header_t.
---
x86_64/copy_user.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/x86_64/copy_user.c b/x86_64/copy_user.c
index 86d23525..ae17c368 100
Sergey Bugaev, le lun. 27 févr. 2023 20:03:07 +0300, a ecrit:
> On Mon, Feb 27, 2023 at 7:39 PM Samuel Thibault
> wrote:
> > > Are there any tests for this at all?
> >
> > It's very difficult to test since it's all about race conditions, with
> > the interruption happening exactly at the wrong mo
On Mon, Feb 27, 2023 at 7:39 PM Samuel Thibault wrote:
> > Are there any tests for this at all?
>
> It's very difficult to test since it's all about race conditions, with
> the interruption happening exactly at the wrong moment.
Right, but can't it be made reliable with some creative use of
ptrac
Hello,
Sergey Bugaev, le lun. 27 févr. 2023 16:39:19 +0300, a ecrit:
> Does my reasoning make sense? Am I missing anything? Was this a simple
> oversight of 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0,
It most probably was, yes.
> Are there any tests for this at all?
It's very difficult to test si
Hello yet again!
I'm looking at sysdeps/mach/hurd/i386/intr-msg.h in glibc -- with the
intention of eventually porting it to x86_64, but that's out of the
question for now, trying to understand it first. The three other
relevant source files for it seem to be:
1. hurd/intr-msg.c -- this is the mai
26 matches
Mail list logo
