Hi Sergey,
this looks like a great work!
Il 19/03/23 16:09, Sergey Bugaev ha scritto:
> I was unable to actually get it running on GNU Mach. It either never gets
> started, or crashes soon enough. The latter is actually to be expected, since
> the kernel does not actually support i386_fsgs_base_state yet. I was unable
> to investigate what exactly happens, because in addition to the troubles with
> actually running GNU Mach on qemu-system-x86_64 (-kernel doesn't work..., you
> really have to build an image with GRUB) and attaching a debugger to it
> (either GDB or QEMU get utterly confused be the switch to the long mode...),
> I had troubles with actually spawning the task while breaking on its first
> instruction (a la starti). In particular prompt-task-resume didn't seem to
> work for me, nor did breaking somewhere before the task should have been
> resumed.
>
> So I would appreciate some help with both testing this patchset (i.e. if you
> do have a working x86_64 Mach + userspace setup, build glibc and try to run
> it), and some general tips about how I would go about debugging the bootstrap
> task from the first instruction onwards with x86_64 GNU Mach, QEMU, and GDB.
One reason for troubles in testing with gnumach is that rpc don't work
very well yet... Simple syscalls should work if you take my patch with
syscall64 v3, and also some simple rpcs, but in general I still see some
issues with the 64-bit message format and the mig-generated stubs. I
still have most of my tests failing with a 64-bit userspace.
I tested with your syscall64 v3. It seems most programs do not work because
the user stack is not aligned correctly. I sent a patch to align it to 16 bytes (seems
like that's what most other OSes use nowadays) and that fixed a bunch.
That being said, once we have fully working rpcs, I think you could have
a "hello-static-glibc" bootstrap module, and assemble a grub rescue disk
to test it on gnumach, much like my "hello" test. For this you could
also take the commit [0] and add your bootstrap module manually, to
reuse the grub disk generation part. Once this works, you should be able
to build ext2fs.static, exec.static and run a "hello-dynamic-glibc" test
by replacing /hurd/startup, which is the first dynamically-linked
executable started. For this case creating a minimal bootable disk is a
bit more tricky, I did it once and I should have some scripts that could
be reused.
In your case you probably need to build a cross-compiler targeting
hurd64, maybe with Flavio's scripts (in my tests I use the
-ffreestanding environment so I can compile them on GNU/Linux). I'm not
sure how this could be optimized for iterative development.
About debugging, the nice thing is that you can load the debug symbols
of the bootstrap module in the same gdb remote session used to debug
gnumach, with:
add-symbol-file <your-path>/module-hello-static-glibc
and you can single-step, use breakpoints etc. on both the user and
kernel code. For example, you can set a breakpoint on the user entry
point _start() and single-step from there.
Also, when you attach gdb to qemu, you should avoid setting a breakpoint
too early, but anything after setup_main() should be ok. So if you want
to set a breakpoint on _start(), I suggest you do it after reaching
setup_main(), otherwise it will also stop on gnumach's own _start(), and
that will indeed mess up with segmentation and long mode.
I hope this helps,
Luca
[0]
https://gitlab.com/luckyd/gnumach/-/commit/cb00d39edc6604cfb485161e85720e23f167d819