On Tue, May 16, 2023 at 6:02 PM Flávio Cruz <flaviocruz@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