On Wed, Feb 15, 2023 at 8:51 AM Flávio Cruz <flavioc...@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
