On Thu, Feb 16, 2023 at 4:19 AM Sergey Bugaev <buga...@gmail.com> wrote:
> 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. > Thanks for the instructions. I discovered that mach_msg_type_long_t does not align to 8 bytes so it also needs a bit of padding just like mach_msg_type_t. See my last patch. I was able to compile most of the glibc and all the stubs after this change. > > >> 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)))? > Yes, this would work too. Mig is adding the padding manually but we could also force alignment or just add padding as needed in the structure directly. I might look into doing that later. > Sergey >
