[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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,


[0] https://gitlab.com/luckyd/gnumach/-/commit/cb00d39edc6604cfb485161e85720e23f167d819

reply via email to

[Prev in Thread] Current Thread [Next in Thread]