Hi Sergey Sorry for the late reply, I have been busy with work and also traveling.
On Tue, May 16, 2023 at 8:41 AM Sergey Bugaev <buga...@gmail.com> wrote: > On Tue, May 16, 2023 at 6:02 PM Flávio Cruz <flavioc...@gmail.com> wrote: > > Yes, I meant this when I said "generate code to call the server reply > routine > > in case of errors". > > Ah, I see. > > > Take the example of the term translator, it forces TypeCheck to be 0 so > that > > it can still receive replies in the error case (otherwise BAD_TYPECHECK > would fail). > > MiG itself should generate an updated stub code that first checks the > > return code and, in case of error, assume the message has the shape of > > mig_reply_header_t. I believe term currently gets garbage values for all > > other missing arguments. > > So *that* what type checking being optional is useful for! Makes > sense, thank you. > > But let me emphasize once again that retcode needs special handling on > both client and server sides, to produce and consume error messages > properly. > > Sergey > > P.S. I too am very interested in whether you would be able to get > something booting and working on x86_64 with your cross-hurd > mini-distro. I see you have pushed the buildsystem changes to build > for x86_64-gnu; have you tried to get it working? I have made changes so that it does daily builds and I'm able to boot small programs. However, I haven't had the time to boot programs built against Glibc. How do you package and boot the static binaries using a ramdisk? I've been reading the other threads about the Guix/rumpkernel so I might be able to piece something together and try it this weekend. > > I'll soon post another series of glibc fixes, so maybe consider trying > them out before they land upstream. You're also going to need [0]. And > you have to use either ramdisk or rumpdisk; just passing device:hd0s1 > is not going to work without in-kernel IDE drivers. > > [0]: https://sourceware.org/pipermail/libc-alpha/2023-April/147734.html >
