Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

[Luca]

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-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