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

[Sergey Bugaev]

On Wed, Feb 15, 2023 at 8:51 AM Flávio Cruz <flaviocruz@gmail.com> wrote:
>> This would be trivial to fix by flipping the line order in aclocal.m4
>> (in each repo that vendors it...), but maybe MIG should actually
>> support this? What does it need the subsystem for anyway, when parsing
>> type defs? Apple's MIG supports this, too.
>
>
> From what I remember, I fixed a bug where we were initializing the basic 
> types twice (see 
> https://git.savannah.gnu.org/cgit/hurd/mig.git/commit/?id=f51fc836c5b690f5448e76196dd40bdb55957a11)
>  and so the type initialization is now made after knowing the subsystem since 
> for the kernel ports could be 8-bytes, while in user mode they are 4-bytes 
> (they are port names).

Hm, right, that makes sense.

Must be way too late to bring this up, but -- why has mach_port_t been
kept 32-bit wide on x64? Wouldn't it be simpler to typedef unsigned
long mach_port_name_t?

> I suggest we fix this in the short term and eventually once we have a better 
> message layout for 64 bits, we can align all port descriptors to be 8-bytes 
> like we did for mach_msg_header_t and then mig can compute the port size 
> statically again.

So if alignof(mach_msg_type_t) = 8, then MIG would not really care if
mach_port_t is 4- or 8-bytes wide, since it will effectively take up 8
bytes when placed inside a message body struct -- is that what you
mean?

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.

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?

Alternatively, maybe MIG should not even try to get this right, and
instead just generate whatever sizeof () and alignof () expressions
are required to tap into GCC's own idea of this.

What do you think?

Sergey