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

["Flávio Cruz" <flaviocruz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3872 bytes --]

Nice work indeed Sergey!

On Sun, Mar 19, 2023 at 12:44 PM Luca <luca@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
>