[RFC PATCH 0/12] Towards glibc on x86_64-gnu

Hello! Seeing that the patches to make binutils and GCC support --target=x86_64-gnu have recently landed, I thought it would be interesting to try to configure glibc with --host=x86_64-gnu and see what breaks. To make things work at least somewhat, I've tried to put some basic directory & Implies

[RFC PATCH glibc 12/12] C11 thrd: Downgrade the default alignment of mtx_t

..so that it can match the alignment of pthread_mutex_t on x86_64-gnu. This likely breaks many other arches (if not all of them), though. Signed-off-by: Sergey Bugaev --- sysdeps/pthread/threads.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/pthread/threads.h b/sys

[RFC PATCH glibc 3/12] mach, hurd: Cast through uintptr_t

When casting between a pointer and an integer of a different size, GCC emits a warning (which is escalated to a build failure by -Werror). Indeed, if what you start with is a pointer, which you then cast to a shorter integer and then back again, you're going to cut off some bits of the pointer. Bu

[RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

tls.h in particular is very unfinished. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/static-start.S | 27 +++ sysdeps/mach/hurd/x86_64/tls.h | 182 sysdeps/mach/hurd/x86_64/tlsdesc.sym| 22 +++ sysdeps/x86_64/htl/bits/pthreadtypes-arch

[RFC PATCH mig 7/12] Drop -undef -ansi from cpp flags

Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3, i386/machine_types.defs defines types based on defined(__x86_64__). Supressing the built-in macro definitions will now result in the wrong type being silently selected. -undef was initially introduced in commit 78b6a7665db7b2eae367e17

[RFC PATCH glibc 5/12] htl: Fix semaphore reference

'sem' is the opaque 'sem_t', 'isem' is the actual 'struct new_sem'. Signed-off-by: Sergey Bugaev --- sysdeps/htl/sem-timedwait.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sysdeps/htl/sem-timedwait.c b/sysdeps/htl/sem-timedwait.c index 8f2df6e7..9974e9ae 10064

[RFC PATCH glibc 1/12] hurd: Refactor readlinkat()

Make the code flow more linear using early returns where possible. This makes it so much easier to reason about what runs on error / successful code paths. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/readlinkat.c | 55 -- 1 file changed, 32 insertions(+), 2

[RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

Signed-off-by: Sergey Bugaev --- mach/Makefile | 3 ++- sysdeps/mach/configure| 6 +++--- sysdeps/mach/configure.ac | 6 +++--- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/mach/Makefile b/mach/Makefile index 39358fdb..f2fdd7da 100644 --- a/mach/Makefile +++ b/ma

[RFC PATCH mig 8/12] Set max type alignment to sizeof(long)

...not sizeof(int). This appears to be required on x86_64. PLEASE NOTE: There is now a patch from Flavio Cruz ("Make MIG work for pure 64 bit kernel and userland") that appears to tackle this same issue (and more). Most likely this simplistic patch should be dropped in favor of the one from Flavio

[RFC PATCH glibc 4/12] hurd: Fix xattr error value

This does not seem like it is supposed to return negative error codes. Signed-off-by: Sergey Bugaev --- hurd/xattr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hurd/xattr.c b/hurd/xattr.c index 48914bcf..5a0fc263 100644 --- a/hurd/xattr.c +++ b/hurd/xattr.c @@ -68,7 +68,

[RFC PATCH glibc 10/12] hurd: Set up the basic tree for x86_64-gnu

And move pt-setup.c to the generic x86 tree. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/Implies | 1 + sysdeps/mach/hurd/{i386 => x86}/htl/pt-setup.c | 4 ++-- sysdeps/mach/hurd/x86_64/Implies | 2 ++ sysdeps/mach/hurd/x86_64/htl/Implies | 3 +

[RFC PATCH glibc 2/12] hurd: Use mach_msg_type_number_t where appropriate

It has been decided that on x86_64, mach_msg_type_number_t stays 32-bit. Therefore, it's not possible to use mach_msg_type_number_t interchangeably with size_t, in particular this breaks when a pointer to a variable is passed to a MIG routine. Signed-off-by: Sergey Bugaev --- hurd/hurdioctl.c

[RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

--- hurd/tioctl.defs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hurd/tioctl.defs b/hurd/tioctl.defs index 905a4a38..a04f5ae4 100644 --- a/hurd/tioctl.defs +++ b/hurd/tioctl.defs @@ -34,9 +34,9 @@ import ; /* XXX */ /* These are the pieces of a struct termios as spec

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

Il 12/02/23 07:15, Flavio Cruz ha scritto: Made changes to MIG so that generated stubs can be compiled when using a 64 bit userland. The most important change here is to ensure that data is always 8-byte aligned. Not doing that will lead to undefined behavior since on 64 bits many structures can

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

Hello, Flavio Cruz, le dim. 12 févr. 2023 01:15:05 -0500, a ecrit: > diff --git a/configure.ac b/configure.ac > index e4645bd..8d52d5f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -55,6 +55,13 @@ AC_SUBST([MIGCOM]) > [MIG=`echo mig | sed "$program_transform_name"`] > AC_SUBST([MIG]) >

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

Thanks for your work on the 64bit RPC part, that's tricky :) Flavio Cruz, le dim. 12 févr. 2023 01:15:05 -0500, a ecrit: > diff --git a/cpu.sym b/cpu.sym > index 6bcb878..7858b47 100644 > --- a/cpu.sym > +++ b/cpu.sym > @@ -95,8 +95,8 @@ expr MACH_MSG_TYPE_POLYMORPHIC > > > /* Types used in i

Re: [RFC PATCH glibc 1/12] hurd: Refactor readlinkat()

Applied, thanks! Sergey Bugaev via Libc-alpha, le dim. 12 févr. 2023 14:10:32 +0300, a ecrit: > Make the code flow more linear using early returns where possible. This > makes it so much easier to reason about what runs on error / successful > code paths. > > Signed-off-by: Sergey Bugaev > --- >

Re: [RFC PATCH glibc 2/12] hurd: Use mach_msg_type_number_t where appropriate

Applied, thanks! Sergey Bugaev via Libc-alpha, le dim. 12 févr. 2023 14:10:33 +0300, a ecrit: > It has been decided that on x86_64, mach_msg_type_number_t stays 32-bit. > Therefore, it's not possible to use mach_msg_type_number_t > interchangeably with size_t, in particular this breaks when a poin

Re: [RFC PATCH glibc 3/12] mach, hurd: Cast through uintptr_t

Applied, thanks! Sergey Bugaev, le dim. 12 févr. 2023 14:10:34 +0300, a ecrit: > When casting between a pointer and an integer of a different size, GCC > emits a warning (which is escalated to a build failure by -Werror). > Indeed, if what you start with is a pointer, which you then cast to a > sh

Re: [RFC PATCH glibc 4/12] hurd: Fix xattr error value

Applied, thanks! Sergey Bugaev, le dim. 12 févr. 2023 14:10:35 +0300, a ecrit: > This does not seem like it is supposed to return negative error codes. > > Signed-off-by: Sergey Bugaev > --- > hurd/xattr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hurd/xattr.c b/

Re: [RFC PATCH glibc 5/12] htl: Fix semaphore reference

Applied, thanks! Sergey Bugaev, le dim. 12 févr. 2023 14:10:36 +0300, a ecrit: > 'sem' is the opaque 'sem_t', 'isem' is the actual 'struct new_sem'. > > Signed-off-by: Sergey Bugaev > --- > sysdeps/htl/sem-timedwait.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

We don't need these to be 64bits, 32bit will be completely large enough. Which issue did you actually encounter? Samuel Sergey Bugaev, le dim. 12 févr. 2023 14:10:37 +0300, a ecrit: > --- > hurd/tioctl.defs | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hurd/tioct

Re: [RFC PATCH mig 7/12] Drop -undef -ansi from cpp flags

Sergey Bugaev, le dim. 12 févr. 2023 14:10:38 +0300, a ecrit: > Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3, > i386/machine_types.defs defines types based on defined(__x86_64__). > Supressing the built-in macro definitions will now result in the wrong > type being silently select

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

Sergey Bugaev, le dim. 12 févr. 2023 14:10:40 +0300, a ecrit: > Signed-off-by: Sergey Bugaev > --- > mach/Makefile | 3 ++- > sysdeps/mach/configure| 6 +++--- > sysdeps/mach/configure.ac | 6 +++--- > 3 files changed, 8 insertions(+), 7 deletions(-) > > diff --git a/mach/Makefil

Re: [RFC PATCH glibc 10/12] hurd: Set up the basic tree for x86_64-gnu

Sergey Bugaev, le dim. 12 févr. 2023 14:10:41 +0300, a ecrit: > And move pt-setup.c to the generic x86 tree. > > Signed-off-by: Sergey Bugaev > --- > sysdeps/mach/hurd/Implies | 1 + > sysdeps/mach/hurd/{i386 => x86}/htl/pt-setup.c | 4 ++-- > sysdeps/mach/hurd/x86_64/Implie

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

On Sun, Feb 12, 2023 at 6:00 PM Samuel Thibault wrote: > We don't need these to be 64bits, 32bit will be completely large enough. > > Which issue did you actually encounter? Well, these MIG definitions need to match the ones in C/glibc. In hurd/ioctl_types.h (in the Hurd tree) there is typedef t

Re: [RFC PATCH glibc 12/12] C11 thrd: Downgrade the default alignment of mtx_t

Sergey Bugaev, le dim. 12 févr. 2023 14:10:43 +0300, a ecrit: > ..so that it can match the alignment of pthread_mutex_t on x86_64-gnu. I'd say rather make pthread_mutex_t aligned on long int, so we can possibly in the future put some pointers in it without breaking the ABI. > This likely breaks m

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

Sergey Bugaev, le dim. 12 févr. 2023 18:15:57 +0300, a ecrit: > On Sun, Feb 12, 2023 at 6:00 PM Samuel Thibault > wrote: > > We don't need these to be 64bits, 32bit will be completely large enough. > > > > Which issue did you actually encounter? > > Well, these MIG definitions need to match the

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

> > # Translate GNU names for CPUs into the names used in Mach header files. > > -mach-machine = $(patsubst powerpc,ppc,$(base-machine)) > > +mach-machine := $(patsubst powerpc,ppc,$(base-machine)) > > +mach-machine := $(patsubst x86_64,i386,$(mach-machine)) > > Mmm, no, it's not actually a transl

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

Sergey Bugaev, le dim. 12 févr. 2023 18:38:03 +0300, a ecrit: > Since mach/machine/syscall_sw.h is the i386 version on x86_64 (or -- > is it not supposed to be?) Nobody yet decided that the system call interface would be the same on i386 and on x86_64 :) Most probably we'll need a different heade

Re: [RFC PATCH glibc 12/12] C11 thrd: Downgrade the default alignment of mtx_t

On Sun, Feb 12, 2023 at 6:18 PM Samuel Thibault wrote: > I'd say rather make pthread_mutex_t aligned on long int, so we can > possibly in the future put some pointers in it without breaking the ABI. I honestly have 0 idea how it is not 8-aligned right now (nor how its size is 32 and not like 56),

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too

On Sun, Feb 12, 2023 at 6:46 PM Samuel Thibault wrote: > > Sergey Bugaev, le dim. 12 févr. 2023 18:38:03 +0300, a ecrit: > > Since mach/machine/syscall_sw.h is the i386 version on x86_64 (or -- > > is it not supposed to be?) > > Nobody yet decided that the system call interface would be the same o

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

Hi, Il 12/02/23 14:37, Luca ha scritto: Il 12/02/23 07:15, Flavio Cruz ha scritto: For the 64 bit / 32 bit configuration, we can pass --enable-user32 when targeting x86_64, and MIG will generate stubs as before. I am unsure whether there exists undefined behavior in that particular configuratio

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

On Sun, Feb 12, 2023 at 7:01 PM Luca wrote: > It seems XNU's mig [0] always sets the alignment to natural_t (=4) with > a #pragma... I still have to understand how they handle these issues. Please note that XNU uses "untyped messaging", and Apple's version of MIG is "untyped MIG". They don't have

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: > It seems that GCC expects TLS on x86_64 to be done relative to %fs, not %gs, > so > that's what I attempted to do in tls.h. The main thing missing there is the > ability to actually set (and read) the %fs base address of a thread. It

Re: [RFC PATCH 0/12] Towards glibc on x86_64-gnu

Hello, Sergey Bugaev via Libc-alpha, le dim. 12 févr. 2023 14:10:31 +0300, a ecrit: > The main missing pieces seem to be, ordered by scariness increasing: > - missing x86_64 thread state definition in the kernel headers; > - TLS things; > - INTR_MSG_TRAP. INTR_MSG_TRAP shouldn't be hard. It's the

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

On Sun, Feb 12, 2023 at 6:22 PM Samuel Thibault wrote: > I'd rather say drop the "long" part, to avoid having to pull the > stdint.h header in. That's what I meant, yes. > Nowadays' BSD headers just use the int type, > notably. So given that the Linux port has its own bits/termios.h, is it fine

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault wrote: > > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: > > We should not need a getter routine, because one can simply inspect the > > target > > thread's state (unless, again, I misunderstand things horribly). > > For 16bit fs/gs

Re: [RFC PATCH glibc 12/12] C11 thrd: Downgrade the default alignment of mtx_t

Sergey Bugaev, le dim. 12 févr. 2023 18:52:37 +0300, a ecrit: > On Sun, Feb 12, 2023 at 6:18 PM Samuel Thibault > wrote: > > I'd say rather make pthread_mutex_t aligned on long int, so we can > > possibly in the future put some pointers in it without breaking the ABI. > > I honestly have 0 idea

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

Sergey Bugaev, le dim. 12 févr. 2023 19:13:58 +0300, a ecrit: > On Sun, Feb 12, 2023 at 6:22 PM Samuel Thibault > wrote: > > I'd rather say drop the "long" part, to avoid having to pull the > > stdint.h header in. > > That's what I meant, yes. > > > Nowadays' BSD headers just use the int type,

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

Il 12/02/23 17:05, Sergey Bugaev ha scritto: On Sun, Feb 12, 2023 at 7:01 PM Luca wrote: It seems XNU's mig [0] always sets the alignment to natural_t (=4) with a #pragma... I still have to understand how they handle these issues. Please note that XNU uses "untyped messaging", and Apple's ver

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: > On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault > wrote: > > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: > > > We should not need a getter routine, because one can simply inspect the > > > target > > > thread's sta

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

* Samuel Thibault via Libc-alpha: > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: >> On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault >> wrote: >> > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: >> > > We should not need a getter routine, because one can simply ins

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

Florian Weimer, le dim. 12 févr. 2023 17:40:58 +0100, a ecrit: > * Samuel Thibault via Libc-alpha: > > > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: > >> On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault > >> wrote: > >> > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ec

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

On Sun, Feb 12, 2023 at 7:36 PM Samuel Thibault wrote: > > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: > > On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault > > wrote: > > > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit: > > > > We should not need a getter routine,

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

Sergey Bugaev, le dim. 12 févr. 2023 19:51:33 +0300, a ecrit: > On Sun, Feb 12, 2023 at 7:36 PM Samuel Thibault > wrote: > > > > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: > > > On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault > > > wrote: > > > > Sergey Bugaev, le dim. 12 fév

[PATCH 4/6] fix rpc time value for 64 bit

* include/mach/task_info.h: use rpc variant of time_value_t * include/mach/thread_info.h: Likewise * kern/mach_clock.c: use rpc variant of time_value_t in read_time_stamp() * kern/mach_clock.h: Likewise * kern/thread.c: use rpc variant of thread_read_times() * kern/timer.h_ add thread_read_times_

[PATCH 3/6] add L4 kmem cache for x86_64

* i386/intel/pmap.c: allocate the L4 page table from a dedicate kmem cache instead of the generic kernel map. Also improve readability of nested ifdef's. --- i386/intel/pmap.c | 34 +++--- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/i386/intel/pm

[PATCH gnumach 0/6] minor fixes and las 32on64 compatibility issue

This series contains some minor fixes set unused members of thread state to 0 fix hardcoded physical address add L4 kmem cache for x86_64 and the last two rpc compatibility issues fix rpc time value for 64 bit fix port name size in notifications then at this stage it seems fine to enable

[PATCH 6/6] enable syscalls on x86_64

Signed-off-by: Luca Dariz --- x86_64/locore.S | 3 --- 1 file changed, 3 deletions(-) diff --git a/x86_64/locore.S b/x86_64/locore.S index 5b9c8ef4..95ece3cc 100644 --- a/x86_64/locore.S +++ b/x86_64/locore.S @@ -1075,9 +1075,6 @@ syscall_entry_2: pushq %rax/* save

[PATCH 1/6] set unused members of thread state to 0

* i386/i386/pcb.c: always set esp to 0, it seems unused. --- i386/i386/pcb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c index 9ac55a1c..924ed08b 100644 --- a/i386/i386/pcb.c +++ b/i386/i386/pcb.c @@ -706,6 +706,7 @@ kern_return_t thread_getstatus(

[PATCH 2/6] fix hardcoded physical address

* i386/i386at/com.c use proper helper to convert physical to virtual address. --- i386/i386at/com.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i386/i386at/com.c b/i386/i386at/com.c index 000475db..de21206c 100644 --- a/i386/i386at/com.c +++ b/i386/i386at/com.c @@ -276,7

[PATCH 5/6] fix port name size in notifications

* ipc/ipc_machdep.h: define PORT_NAME_T_SIZE_IN_BITS * ipc/ipc_notify.c: fix port name size in notification message templates --- ipc/ipc_machdep.h | 1 + ipc/ipc_notify.c | 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/ipc/ipc_machdep.h b/ipc/ipc_machdep.h index 29

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

On Sun, Feb 12, 2023 at 8:02 PM Samuel Thibault wrote: > I'd rather make it a separate state content, like we have a separate > i386_DEBUG_STATE content. > > (And thus no need for a new RPC). Makes sense to me! 👍 Sergey

Re: [PATCH 1/6] set unused members of thread state to 0

Better avoid uninitialized data indeed, applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:03:08 +0100, a ecrit: > * i386/i386/pcb.c: always set esp to 0, it seems unused. > --- > i386/i386/pcb.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c > ind

Re: [PATCH 2/6] fix hardcoded physical address

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:03:09 +0100, a ecrit: > * i386/i386at/com.c use proper helper to convert physical to virtual > address. > --- > i386/i386at/com.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/i386/i386at/com.c b/i386/i386at/com.c

Re: [PATCH 3/6] add L4 kmem cache for x86_64

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:03:10 +0100, a ecrit: > * i386/intel/pmap.c: allocate the L4 page table from a dedicate kmem > cache instead of the generic kernel map. > Also improve readability of nested ifdef's. > --- > i386/intel/pmap.c | 34 +++---

[PATCH 6/9] add more explicit names for user space virtual space limits

* i386/i386/vm_param.h: add VM_MAX/MIN_USER_ADDRESS to kernel headers. * i386/i386/db_interface.c * i386/i386/ldt.c * i386/i386/pcb.c * i386/intel/pmap.c * kern/task.c: replace VM_MAX/MIN_ADDRESS with VM_MAX/MIN_USER_ADDRESS --- i386/i386/db_interface.c | 4 ++-- i386/i386/ldt.c | 8 +++

[PATCH 2/9] fix x86_64 asm for higher kernel addresses

* x86_64/interrupt.S: use 64-bit registers as variables could be stored at high addresses * x86_64/locore.S: Likewise --- x86_64/interrupt.S | 4 ++-- x86_64/locore.S| 6 ++ 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/x86_64/interrupt.S b/x86_64/interrupt.S index fe2b3

[PATCH 9/9] move kernel virtual address space to upper addresses

* i386/i386/vm_param.h: adjust constants to the new kernel map - the boothdr.S code already sets up a temporary map to higher addresses, so we can use INIT_VM_MIN_KERNEL_ADDRESS as in xen - increase the kernel map size to accomodate for bigger structures and more memory - adjust kerne

Re: [PATCH 4/6] fix rpc time value for 64 bit

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:03:11 +0100, a ecrit: > * include/mach/task_info.h: use rpc variant of time_value_t > * include/mach/thread_info.h: Likewise > * kern/mach_clock.c: use rpc variant of time_value_t in > read_time_stamp() > * kern/mach_clock.h: Likewise > * ker

[PATCH 5/9] use L4 page table directly on x86_64 instead of short-circuiting to pdpbase

This is a preparation to run the kernel on high addresses, where the user vm region and the kernel vm region will use different L3 page tables. * i386/intel/pmap.c: on x86_64, retrieve the value of pdpbase from the L4 table, and add the pmap_pdp() helper (useful also for PAE). * i386/intel/pmap.

[PATCH 4/9] factor out PAE-specific bootstrap

* i386/intel/pmap.c: move it to pmap_bootstrap_pae() --- i386/intel/pmap.c | 72 ++- 1 file changed, 40 insertions(+), 32 deletions(-) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index 15577a09..470be744 100644 --- a/i386/intel/pmap.c +++ b/i386/

[PATCH 8/9] separate initialization of kernel and user PTP tables

* i386/i386/vm_param.h: temporariliy fix kernel upper address * i386/intel/pmap.c: split kernel and user L3 map initialization. For simplicity in handling the different configurations, on 32-bit (+PAE) the name PDPNUM_KERNEL is used in place of PDPNUM, while only on x86_64 the PDPNUM_USER and

[PATCH 0/9 gnumach] move kernel vm map to high addresses on x86_64

The kernel vm region is moved to the last 2GB of the 64-bit address space. According to the -mcmodel=kernel, the code must be placed in this range, but probably other addresses can be used for other data structures, direct memory mapping and so on (as in Linux). This is just the first step towards

[PATCH 3/9] factor out xen-specific bootstrap

* i386/intel/pmap.c: move it to pmap_bootstrap_xen() --- i386/intel/pmap.c | 107 -- 1 file changed, 56 insertions(+), 51 deletions(-) diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c index 9fe16368..15577a09 100644 --- a/i386/intel/pmap.c +++ b/i386/

[PATCH 7/9] extend data types to hold a 64-bit address

* i386/i386/trap.c: change from int to a proper type to hold a register value * x86_64/locore.S: use 64-bit register to avoid address truncation --- i386/i386/trap.c | 12 ++-- x86_64/locore.S | 4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/i386/i386/trap.c b/i

[PATCH 1/9] prepare pmap helpers for full 64 bit memory map

* i386/intel/pmap.c: start walking the page table tree from the L4 table instead of the PDP table in pmap_pte() and pmap_pde(), preparing for the kernel to run on high addresses. --- i386/intel/pmap.c | 28 +++- 1 file changed, 23 insertions(+), 5 deletions(-) diff --g

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

On Sun, Feb 12, 2023 at 11:34 AM Luca wrote: > Il 12/02/23 17:05, Sergey Bugaev ha scritto: > > On Sun, Feb 12, 2023 at 7:01 PM Luca wrote: > >> It seems XNU's mig [0] always sets the alignment to natural_t (=4) with > >> a #pragma... I still have to understand how they handle these issues. > >

Re: [PATCH 5/6] fix port name size in notifications

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:03:12 +0100, a ecrit: > * ipc/ipc_machdep.h: define PORT_NAME_T_SIZE_IN_BITS > * ipc/ipc_notify.c: fix port name size in notification message > templates > --- > ipc/ipc_machdep.h | 1 + > ipc/ipc_notify.c | 8 > 2 files changed, 5

Re: [PATCH 6/6] enable syscalls on x86_64

Applied, thanks Luca Dariz, le dim. 12 févr. 2023 18:03:13 +0100, a ecrit: > Signed-off-by: Luca Dariz > --- > x86_64/locore.S | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/x86_64/locore.S b/x86_64/locore.S > index 5b9c8ef4..95ece3cc 100644 > --- a/x86_64/locore.S > +++ b/x86_

Re: [PATCH 0/9 gnumach] move kernel vm map to high addresses on x86_64

Il 12/02/23 18:28, Luca Dariz ha scritto: The kernel vm region is moved to the last 2GB of the 64-bit address space. According to the -mcmodel=kernel, the code must be placed in this range, but probably other addresses can be used for other data structures, direct memory mapping and so on (as in

Re: [PATCH 1/9] prepare pmap helpers for full 64 bit memory map

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:10 +0100, a ecrit: > * i386/intel/pmap.c: start walking the page table tree from the L4 > table instead of the PDP table in pmap_pte() and pmap_pde(), > preparing for the kernel to run on high addresses. > --- > i386/intel/pmap.c | 28 +

Re: [PATCH 2/9] fix x86_64 asm for higher kernel addresses

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:11 +0100, a ecrit: > * x86_64/interrupt.S: use 64-bit registers as variables could be > stored at high addresses > * x86_64/locore.S: Likewise > --- > x86_64/interrupt.S | 4 ++-- > x86_64/locore.S| 6 ++ > 2 files changed, 4 inse

Re: [PATCH 3/9] factor out xen-specific bootstrap

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:12 +0100, a ecrit: > * i386/intel/pmap.c: move it to pmap_bootstrap_xen() > --- > i386/intel/pmap.c | 107 -- > 1 file changed, 56 insertions(+), 51 deletions(-) > > diff --git a/i386/intel/pmap.

Re: [PATCH 4/9] factor out PAE-specific bootstrap

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:13 +0100, a ecrit: > * i386/intel/pmap.c: move it to pmap_bootstrap_pae() > --- > i386/intel/pmap.c | 72 ++- > 1 file changed, 40 insertions(+), 32 deletions(-) > > diff --git a/i386/intel/pmap.

[PATCH mig] Make MIG work for pure 64 bit kernel and userland (V2)

Made changes to MIG so that generated stubs can be compiled when using a 64 bit userland. The most important change here is to ensure that data is always 8-byte aligned. Not doing that will lead to undefined behavior since on 64 bits many structures can contain 64 bit scalars which require 8-byte a

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.

On Sun, Feb 12, 2023 at 9:44 AM Samuel Thibault wrote: > Thanks for your work on the 64bit RPC part, that's tricky :) > > Flavio Cruz, le dim. 12 févr. 2023 01:15:05 -0500, a ecrit: > > diff --git a/cpu.sym b/cpu.sym > > index 6bcb878..7858b47 100644 > > --- a/cpu.sym > > +++ b/cpu.sym > > @@ -95

Re: [PATCH 5/9] use L4 page table directly on x86_64 instead of short-circuiting to pdpbase

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:14 +0100, a ecrit: > This is a preparation to run the kernel on high addresses, where the > user vm region and the kernel vm region will use different L3 page > tables. > > * i386/intel/pmap.c: on x86_64, retrieve the value of pdpbase from

Re: [PATCH 6/9] add more explicit names for user space virtual space limits

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:15 +0100, a ecrit: > * i386/i386/vm_param.h: add VM_MAX/MIN_USER_ADDRESS to kernel headers. > * i386/i386/db_interface.c > * i386/i386/ldt.c > * i386/i386/pcb.c > * i386/intel/pmap.c > * kern/task.c: replace VM_MAX/MIN_ADDRESS with VM_MAX/MI

Re: [PATCH 7/9] extend data types to hold a 64-bit address

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:16 +0100, a ecrit: > * i386/i386/trap.c: change from int to a proper type to hold a > register value > * x86_64/locore.S: use 64-bit register to avoid address truncation > --- > i386/i386/trap.c | 12 ++-- > x86_64/locore.S | 4

[PATCH gnumach] Consider protected payloads in mach_msg_header_t when resizing messages.

Protected payloads will be 8-byte longs which are the same size as kernel ports. Also aligned all the structures to be 4-byte aligned since it makes it easier to parse them as padding won't be added to mach_msg_user_header_t before the protected payload. --- include/mach/message.h | 9 -

Re: [PATCH 8/9] separate initialization of kernel and user PTP tables

Applied, thanks! Luca Dariz, le dim. 12 févr. 2023 18:28:17 +0100, a ecrit: > * i386/i386/vm_param.h: temporariliy fix kernel upper address > * i386/intel/pmap.c: split kernel and user L3 map initialization. For > simplicity in handling the different configurations, on 32-bit > (+PAE) the name

Re: [PATCH 9/9] move kernel virtual address space to upper addresses

Applied, thanks!! Luca Dariz, le dim. 12 févr. 2023 18:28:18 +0100, a ecrit: > * i386/i386/vm_param.h: adjust constants to the new kernel map > - the boothdr.S code already sets up a temporary map to higher > addresses, so we can use INIT_VM_MIN_KERNEL_ADDRESS as in xen > - increase the ke

[PATCH gnumach] Add x86_64 registers to i386_thread_state

This is required to implement ptrace. --- i386/i386/pcb.c| 42 +- i386/include/mach/i386/thread_status.h | 28 + 2 files changed, 69 insertions(+), 1 deletion(-) diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c index 9ac55a1c..ba856523

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland (V2)

Flavio Cruz, le dim. 12 févr. 2023 12:49:44 -0500, a ecrit: > For the 64 bit / 32 bit configuration, we can pass --enable-user32 when > targeting x86_64, and MIG will generate stubs as before. I am unsure > whether there exists undefined behavior in that particular configuration > since most of the

Re: [PATCH gnumach] Consider protected payloads in mach_msg_header_t when resizing messages.

Applied, thanks! Flavio Cruz, le dim. 12 févr. 2023 13:11:13 -0500, a ecrit: > Protected payloads will be 8-byte longs which are the same size as > kernel ports. > > Also aligned all the structures to be 4-byte aligned since it makes it > easier to parse them as padding won't be added to mach_msg

Re: [RFC PATCH mig 7/12] Drop -undef -ansi from cpp flags

On Sun, Feb 12, 2023 at 10:02 AM Samuel Thibault wrote: > Sergey Bugaev, le dim. 12 févr. 2023 14:10:38 +0300, a ecrit: > > Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3, > > i386/machine_types.defs defines types based on defined(__x86_64__). > > Supressing the built-in macro def

Re: [RFC PATCH mig 7/12] Drop -undef -ansi from cpp flags

Applied, thanks! Sergey Bugaev, le dim. 12 févr. 2023 14:10:38 +0300, a ecrit: > Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3, > i386/machine_types.defs defines types based on defined(__x86_64__). > Supressing the built-in macro definitions will now result in the wrong > type bei

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

Applied, thanks! Flavio Cruz, le dim. 12 févr. 2023 13:26:29 -0500, a ecrit: > This is required to implement ptrace. > --- > i386/i386/pcb.c| 42 +- > i386/include/mach/i386/thread_status.h | 28 + > 2 files changed, 69 insertions(+)

Re: [RFC PATCH hurd 6/12] hurd: Fix modes_t and speeds_t types on 64-bit

Applied, thanks! Sergey Bugaev, le dim. 12 févr. 2023 19:13:58 +0300, a ecrit: > On Sun, Feb 12, 2023 at 6:22 PM Samuel Thibault > wrote: > > I'd rather say drop the "long" part, to avoid having to pull the > > stdint.h header in. > > That's what I meant, yes. > > > Nowadays' BSD headers just u

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

* Samuel Thibault: > Florian Weimer, le dim. 12 févr. 2023 17:40:58 +0100, a ecrit: >> * Samuel Thibault via Libc-alpha: >> >> > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: >> >> On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault >> >> wrote: >> >> > Sergey Bugaev, le dim. 12 fév

Re: [RFC PATCH glibc 11/12] hurd, htl: Add some x86_64-specific code

Florian Weimer, le dim. 12 févr. 2023 20:29:43 +0100, a ecrit: > * Samuel Thibault: > > > Florian Weimer, le dim. 12 févr. 2023 17:40:58 +0100, a ecrit: > >> * Samuel Thibault via Libc-alpha: > >> > >> > Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit: > >> >> On Sun, Feb 12, 2023 at

[PATCH hurd] Use rpc_time_value_t in user space to avoid build errors

rpc_time_value_t was introduced in https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=5fdc928d3d29fdc93ad00cea5f5c877a19013d44 but it breaks the build. This change fixes it. --- libps/spec.c | 8 procfs/process.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) di

Re: [PATCH hurd] Use rpc_time_value_t in user space to avoid build errors

Flavio Cruz, le dim. 12 févr. 2023 16:54:52 -0500, a ecrit: > rpc_time_value_t was introduced in > https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=5fdc928d3d29fdc93ad00cea5f5c877a19013d44 > but it breaks the build. Argl, I was wondering a bit about whether exposing rpc_ names could

[PATCH mig] Introduce max_alignof to replace word_size

Remove the concept of word_size since it is meaningless in some architectures. This is also done in preparation to possibly introduce 8-byte aligned messages. --- cpu.sym | 3 +- global.c | 5 +-- global.h | 5 +-- parser.y | 8 ++--- routine.c | 5 ++- server.c | 20 ++-- type.

Re: [PATCH mig] Introduce max_alignof to replace word_size

Renamed to complex_alignof and commited, thanks! Flavio Cruz, le dim. 12 févr. 2023 17:14:23 -0500, a ecrit: > Remove the concept of word_size since it is meaningless in some > architectures. This is also done in preparation to possibly introduce > 8-byte aligned messages. > --- > cpu.sym | 3

[PATCH gnumach] Make mach_msg_header_t have the same size for both 64 bit kernel and userland.

This has several advantages: 1) We don't need to resize mach_msg_header_t, it is just a copy. 2) Mig won't require any changes because it statically computes the size of mach_msg_header_t, otherwise we would need two sizes (28 vs 32 bytes). --- include/mach/message.h | 15 +-- x86_6

Re: [PATCH gnumach] Make mach_msg_header_t have the same size for both 64 bit kernel and userland.

Applied, thanks! Flavio Cruz, le dim. 12 févr. 2023 18:54:58 -0500, a ecrit: > This has several advantages: > 1) We don't need to resize mach_msg_header_t, it is just a copy. > 2) Mig won't require any changes because it statically computes the size > +#else > + if (copyout(&kmsg, &umsg, sizeof(

Re: [PATCH v3] i386: Refactor int stacks to be per cpu for SMP

Applied and fixed for PAE, thanks! Damien Zammit, le sam. 04 févr. 2023 01:15:06 +, a ecrit: > This also serialises the AP bringup, so paging can be enabled per cpu > one by one. > > Also-by: Almudena Garcia > --- > i386/i386/mp_desc.c | 230 > i

  1   2   >