Nice work indeed Sergey! On Sun, Mar 19, 2023 at 12:44 PM Luca <l...@orpolo.org> wrote:
> 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 >
