On Wed, Feb 15, 2023 at 4:05 AM Sergey Bugaev <buga...@gmail.com> wrote:
> 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? > It makes sense from an interface point of view to say that a task can hold up to 2^32 port names. However, that does not prevent us from actually using 8-byte aligned port names just to make it easier for the kernel to copy messages. > > > 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? > Yes. > > 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). > > 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. In a world where both userland and kernel are both 64 bits, 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. > 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 >
