Re: checking whether mig supports the retcode keyword... no

[Sergey Bugaev]

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.

>> 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