IRC channel logs

<damo22>solid_black: do you have time to help investigate the last failing test on user32?

<damo22> "gnumach-test-failure MIG_TYPE_ERROR (0xfffffed4): host_get_time64" for test-mach_host

<damo22>i think i may have found a bug in the ci

<damo22>testing now

<damo22>youpi: does mig need to install any headers or does it just create the mig binary?

<damo22>for example, can i install mig32 into the same prefix as mig64?

<youpi>afaik mig doesn't install headers

<youpi>it's just the binary

<diegonc>(gdb) target remote 127.0.0.1:1234

<diegonc>Remote debugging using 127.0.0.1:1234

<diegonc>warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64

<diegonc>warning: Architecture rejected target-supplied description

<diegonc>Remote 'g' packet reply is too long (expected 312 bytes, got 608 bytes):

<diegonc>==

<diegonc>i get that messages trying to debug gnumach with gdb

<diegonc>do i need some special gdb for user32?

<damo22>user32 is 64 bit gnumach

<damo22>32 bit userspace

<damo22>i have had to close my CI browser to the public

<damo22>i cant fight these bots

<diegonc>yeah, the module-mach_host file is a 32-bit ELF but gnumach is 64-bit

<diegonc>seems ok, but I could have messed the building steps :/

<damo22>see the .forgejo/workflows/action.yaml for build steps

<damo22>it cross compiles all versions

<damo22>using just a x86_64 toolchain

<diegonc>yep I followed that yaml

<diegonc>I had to install gcc's multilib

<damo22>yep

<damo22>i wonder do we need to install i386 headers specifically to build mig32?

<damo22>that is missing from the yaml

<damo22>or are the gnumach headers agnostic to that

<diegonc>ah, there's a gdb-multiarch. and with "set architecture i386:x86-64" gdb can connect to qemu's gdbserver \o/

<diegonc>but I can't step through the code :(

<diegonc>sorta

<diegonc>it steps with show invalid memory addresses

<diegonc>s/with/but/

<solid_black>morning!

<solid_black>damo22: let's investigate your failing tests :)

<damo22>i have the mach_host.user.c

<damo22>i am trying to see why it returns MIG_TYPE_ERROR

<damo22> const mach_msg_type_t current_timeCheck = {

<damo22> .msgt_name = (unsigned char) MACH_MSG_TYPE_INTEGER_32,

<damo22> .msgt_size = 32,

<damo22> .msgt_number = 4,

<damo22> if (mig_unlikely ((OutP->Head.msgh_bits & MACH_MSGH_BITS_COMPLEX) ||

<damo22> ((msgh_size != 52) &&

<damo22> ((msgh_size != sizeof(mig_reply_header_t)) ||

<damo22> (OutP->RetCode == KERN_SUCCESS)))))

<damo22> return MIG_TYPE_ERROR;

<damo22>does that line up

<damo22> typedef struct {

<damo22> mach_msg_header_t Head;

<damo22> mach_msg_type_t RetCodeType;

<damo22> kern_return_t RetCode;

<damo22> mach_msg_type_t current_timeType;

<damo22> time_value64_t current_time;

<damo22> } Reply;

<damo22>time_value64_t is 2x int64_t

<damo22>52 bytes - 16 bytes for the time_value64_t leaves 36 bytes for the rest of the message

<solid_black>is the kernel or the userland returning an error?

<damo22>the rpc returns an error

<damo22>msgt_size : 8, <--- for 32 bit userland... this does not match what the comment says

<solid_black>the above says that current_time is 4 times an int32

<damo22> * Note that for 64 bit userland, msgt_size only needs to be 8 bits long

<damo22> * but for kernel compatibility with 32 bit userland we allow it to be

<damo22> * 16 bits long.

<damo22>mach_msg_type_t looks unusual

<damo22>4 times a int32 is the same as 2 times a int64 right?

<solid_black>the sizes would be the same, but the types are different

<damo22>does mig even support INTEGER_64 ?

<damo22>yeah

<solid_black>I see type int64_t = MACH_MSG_TYPE_INTEGER_64; in std_types.defs, then type time_value64_t = struct { int64_t seconds; int64_t nanoseconds; }; in mach_types.defs

<solid_black>both not conditional on USER32

<damo22>why would it be conditional on that? its the same size for both userlands

<solid_black>so why are you getting 4x MACH_MSG_TYPE_INTEGER_32?

<damo22>i dont know

<damo22>mig bug?

<solid_black>see if you can reproduce it if you run mig yourself

<youpi>the rpc mechanism not only checks for size, but really coherency of types

<youpi>depending on the target platforms it may have differing rules for the typing

<solid_black>my (pissibly wrong, correct me) understanding is that for user32 setup, you would use two different toolchains (including two different migs), one targeting x86_64-gnu, you'd build gnumach with it, and the other one targeting i386-gnu, you'd build your userland with it

<youpi>yes

<solid_black>but is damo22 trying to build the whole thing with the same toolchain and just passing -m32?

<damo22>no i am building mig twice

<damo22>interesting $ ../configure --prefix=/part3/git/gnumach-sv/gnu64 --target=i686-gnu

<damo22>that might be wrong

<solid_black>that does look right

<solid_black>I mean, for building a mig that targets the 32-bit userspace

<solid_black>is the whole build script available?

<solid_black>i.e. can I see it?

<sam_>the distinction between --host and --target matters for toolchain packages, i don't know if it matters for mig specifically but i wouldn't be surprised

<youpi>it does

<solid_black>of course

<solid_black>host is where mig would run, target is what mig generates code for

<sam_>right

<solid_black>off topic, sam_, was it you who dropped G_GNUC_CONST?

<damo22>solid_black: its committed to the repo in .forgejo/workflow/action.yaml

<solid_black>ACTION looks

<solid_black>I see jobs named "i386" and "x86_64", but not user32?

<solid_black>so "gnu32" is the prefix, and "build32" is the build dir

<damo22>yes

<sam_>solid_black: yes

<solid_black>CCASFLAGS -- first time I'm seeing that?

<sam_>i'm a bit surprised that is being used (but not looked at the workflow)

<sam_>(which repo is this in?)

<sam_>upstream mach?

<damo22>yeah

<solid_black>it's for -fdebug-prefix-map /shrug

<solid_black>I'm looking at https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/.forgejo/workflows/action.yaml

<damo22>i wrote that script, it runs in my forgejo instance automatically

<solid_black>so you're building an i686 gnumach with x86_64-linux-gnu-gcc / x86_64-linux-gnu-ld, by passing -m32 and -melf_i386

<damo22>yes

<solid_black>nothing in here is about userland tests however?

<solid_black>or user32

<damo22>make VERBOSE=1 check

<solid_black>aha

<damo22>make VERBOSE=true check

<solid_black>let me read the x86_64 block next

<damo22>it uses -m32 and -melf_i386 for the userspace tests

<solid_black>so it's another matrix, either user32 or not

<damo22>but compiles x86_64 gnumach

<damo22>yeah so this basically tests all combinations

<damo22>it passes on all these except the --enable-user32 tests

<solid_black>when compiling the 32-bit userland against an 64-bit user32-configured kernel headers, is USER32 defined? where from?

<solid_black>also -m32 disables __x86_64__ define, right?

<damo22>hmm

<damo22>do i need to add -DUSER32 or something

<solid_black>I don't know, how is this supposed to work?

<solid_black>is an i386-gnu userland supposed to be buildable against x86_64 user32 mach installation?

<youpi>maybe for a start compare the userland production of 32/32 and 64/32

<youpi>to be actually sure on which side the error is

<youpi>whether it's userland which is miscompiled on 64/32

<youpi>or it's the kernel that misbehaves in 64/32

<damo22>i am not compiling the entire userland

<damo22>just the test framework

<youpi>solid_black: the mach installation in the user32 case is supposed to be exactly the same as pure 32b

<youpi>if not, it's a bug

<solid_black>well, the mach binary is suerly different

<solid_black>but the headers and defs are all the same?

<youpi>but again, to determine this it's a matter of just checking the produced mig stubs

<youpi>whether they do have the same type in 64/32 and 32/32

<youpi>solid_black: they should be the same, yes

<solid_black>damo22: could the CI verify that ^^ ?

<solid_black>aha, so there's USER_MIG, USER_CC, etc, and you're setting them

<solid_black>could not wiping the build dir before reconfiguring affect it?

<damo22>mabe

<damo22>mayeb

<damo22>ugh

<solid_black>single-stepping over 'syscall' in GDB on x86-64 gnu kills Mach

<diegonc>o/

<diegonc>I'm having a look at build-tree/kern/mach_host.server.c and it differs in the returned current_timeType and the expected one in build-tree/mig-out/mach_host.user.c

<diegonc>the server part is returning a size of 72 and a type of (MACH_MSG_TYPE_INTEGER_64, 64 , 2) instead of INTEGER_32 based one in the user part

<diegonc>there's no such difference in a pure i386 build

<diegonc>is it that supposed to be ok? if yes, where is the server type translated to the user type?

<diegonc>also, a full x86_64 build generates code in both server and user files using a size of 72 and a current_timeType of (INTEGER_64., 64. 2)

<solid_black>diegonc: yes, that's what we've been discussing

<solid_black>MACH_MSG_TYPE_INTEGER_64 x2 is correct, INTEGER_32 x4 is unexpected

<diegonc>solid_black,what I meant is that 32x4 is what you get from a mig32 (used for user side) and 64x2 comes from mig64 (used in server side). so the mix used by --enable-user32 is somewhat incompatible with each other (?)

<solid_black>presumably it should be using two different MIGs

<solid_black>at least that's what it appeared to do in damo22's CI script/setup

<solid_black>do you also get MACH_MSG_TYPE_INTEGER_32 x4 on pure i686?

<diegonc>yeap, the CI script specifies both MIG and USER_MIG variables

<diegonc>I'm not sure how gnumach uses them though

<diegonc>tests/configfrag.ac:AC_ARG_VAR([USER_MIG], [Path to the mig tool for user-space tests])

<diegonc>ok, it uses it for tests

<diegonc>configure.ac:AC_ARG_VAR([MIG], [Path to the mig tool])

<diegonc>and I guess the plain mig for the kernel

<diegonc>> solid_black: do you also get MACH_MSG_TYPE_INTEGER_32 x4 on pure i686?

<diegonc>yes

<diegonc>I built gnumach on a i386 image and got 32x4 on both user and server side of the RPC

<solid_black>hmm, can you trace how that happens?

<diegonc>unfortunately I tried readng mig code but couln't find where it's decided to use one or the other :(

<solid_black>I meant more of reading mach_types.defs

<solid_black> https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/mach/mach_types.defs#n274 this does not look conditional on 32 vs 64-bitness of the system

<solid_black>does any usage of time_value64_t result in 32x4? what about usage of int64_t?

<youpi>it's expected that the server side is not the same as the user sid, in the user32 case

<youpi>gnumach translates between the two

<youpi>again, for a start check whether the generated user32 test files match the pure-32 test files

<youpi>to determine whether it's mig which is bogus in the user32 case, or whether it's the translation between kernel64 and user32 which is bogus

<diegonc>solid_black: routing test_int64_t (host: mach_port_t; out n: int64_t)

<diegonc>compiling that on i386 I get a type check of 64x1 :/

<diegonc>youpi, I think they are the same. but I will check again starting with a clean slate on both environments

<diegonc>solid_black: as soon as I place an int64_t into a struct I start getting 32x2 checks

IRC channel logs

2026-06-27.log