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
>

Reply via email to