On Thu, Feb 16, 2023 at 10:27 AM Flávio Cruz <flavioc...@gmail.com> wrote: >> On that note: right now, MIG-generated stubs are broken on x86_64. MIG >> built from master complains about time_value_t (which GCC says is 16 >> bytes-, but MIG expects to be 12 bytes- sized). If I set >> desired_max_alignof to 8 (which it must be, to match GCC), then >> time_value_t works, but some sizeof (struct Request) elsewhere breaks. > > Are you compiling the gnumach stubs? For me, I can compile gnumach without > USER32 (requires desired_max_alignof to be 8) and with USER32 (no changes).
I'm compiling User.c side of GNU Mach defs, as a part of x86_64 glibc build. You can try this for yourself: apply the following patch and run `make -k mach/subdir_objs` diff --git a/mach/Makefile b/mach/Makefile index 39358fdb..f2fdd7da 100644 --- a/mach/Makefile +++ b/mach/Makefile @@ -64,7 +64,8 @@ CFLAGS-RPC_i386_set_ldt.o = $(no-stack-protector) CFLAGS-RPC_task_get_special_port.o = $(no-stack-protector) # 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)) (The -k is needed to continue despite the failures caused by missing thread_state.h). Observe static asserts failing :( The same can probably be reproduced outside of glibc build too. >> Can't we "just" figure out how size/alignment works in C and teach MIG >> to do the very same thing? How hard can it be? > > MIG partially knows how to do that, for example see how we compute the size > of struct types and how we compute the size of the request. I understand, but evidently it still doesn't do that well enough, since its idea of size/alignment differs from GCC's. > In a world where both userland and kernel are both 64 bits, That's the case I'm interested in, yes. > it should be easy. If we pad the message types so that we don't need to > worry about messages being resized and the kernel can still iterate over the > message to replace port names with port pointers, then it just works and > there's no data shifting which would break alignment. We already have many > things in place here, for example, we know the alignment of each data type so > the only missing piece is making mach_msg_type_t (or descriptors, whatever we > end up calling it) play well with the target alignment. So, why can't we just define mach_msg_type_t as __attribute__ ((aligned (8)))? Sergey
