On Thu, Feb 16, 2023 at 10:27 AM Flávio Cruz <flaviocruz@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