bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with


From: Flávio Cruz
Subject: Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.
Date: Thu, 9 Mar 2023 02:39:47 -0500

Hi

On Wed, Mar 8, 2023 at 4:37 AM Sergey Bugaev <bugaevc@gmail.com> wrote:
Hi,

this seems to break the x86_64 --disable-user32 gnumach build for me:

vm/memory_object_user.user.c: In function ‘memory_object_init’:
vm/memory_object_user.user.c:128:9: error: static assertion failed:
"Request expected to be 80 bytes"
  128 |         _Static_assert(sizeof(Request) == 80, "Request
expected to be 80 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_terminate’:
vm/memory_object_user.user.c:197:9: error: static assertion failed:
"Request expected to be 64 bytes"
  197 |         _Static_assert(sizeof(Request) == 64, "Request
expected to be 64 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_copy’:
vm/memory_object_user.user.c:304:9: error: static assertion failed:
"Request expected to be 96 bytes"
  304 |         _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_data_request’:
vm/memory_object_user.user.c:412:9: error: static assertion failed:
"Request expected to be 96 bytes"
  412 |         _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_data_unlock’:
vm/memory_object_user.user.c:520:9: error: static assertion failed:
"Request expected to be 96 bytes"
  520 |         _Static_assert(sizeof(Request) == 96, "Request
expected to be 96 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_lock_completed’:
vm/memory_object_user.user.c:609:9: error: static assertion failed:
"Request expected to be 80 bytes"
  609 |         _Static_assert(sizeof(Request) == 80, "Request
expected to be 80 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_supply_completed’:
vm/memory_object_user.user.c:737:9: error: static assertion failed:
"Request expected to be 112 bytes"
  737 |         _Static_assert(sizeof(Request) == 112, "Request
expected to be 112 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_data_return’:
vm/memory_object_user.user.c:872:9: error: static assertion failed:
"Request expected to be 120 bytes"
  872 |         _Static_assert(sizeof(Request) == 120, "Request
expected to be 120 bytes");
      |         ^~~~~~~~~~~~~~
vm/memory_object_user.user.c: In function ‘memory_object_change_completed’:
vm/memory_object_user.user.c:944:9: error: static assertion failed:
"Request expected to be 64 bytes"
  944 |         _Static_assert(sizeof(Request) == 64, "Request
expected to be 64 bytes");
      |         ^~~~~~~~~~~~~~

Reverting (or rather, rebasing out) this commit helped. Does this
perhaps need matching changes in MIG?

I suspect you have to rebuild MiG because it needs to get the new definitions
for mach_msg_type_t and mach_msg_type_long_t. Let me know if you still run
into problems.
 

And a meta question: is GNU MIG only intended to be usable with the
latest commit of GNU Mach? It certainly generates typed IPC, so it
can't be used with OSF/Apple's Mach. But is it expected to only ever
support whatever 64-bit ABI gnumach *currently* has, or should it
attempt to do some feature detection / whatever? In particular having
MIG generate working code no matter what Mach commit I'm on would be
nice :)

Yes, that would be nice but I'm not sure if we can avoid this when we are
changing the base data types used to encode the messages. I think we just
need to get the gnumach ABI in a more stable place and then it should work
like i686, where it should never break.


Sergey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]