|
From: | Luca |
Subject: | Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port |
Date: | Sun, 19 Mar 2023 17:44:32 +0100 |
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.
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-glibcand 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
[Prev in Thread] | Current Thread | [Next in Thread] |