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

[Sergey Bugaev]

On Tue, Mar 21, 2023 at 11:36 AM Luca <luca@orpolo.org> wrote:
>
> Il 20/03/23 20:10, Sergey Bugaev ha scritto:
> > I've gone through the process again (without GDB, even, for now).
> > Attaching two screenshots: the first one shows what I input to GRUB
> > (seemingly all correct?), on the second one Mach boots, prints "1
> > bootstrap modules" and... just sits there doing nothing. It doesn't
> > prompt me for anything (from the source code, I'd expect "Pausing for
> > %s...\n", "Hit <return> to resume bootstrap.").
> >
> > This is with your and Flavio's latest patches, if that matters.
> >
> > Any ideas?
>
> Can you attach with gdb at this point? IIRC you can also dynamically
> enable/disable the gdb server through the qemu monitor, or stop and see
> the registers from there.

Sure:

(gdb) target rem :1234
Remote debugging using :1234
warning: Remote gdbserver does not support determining executable automatically.
RHEL <=6.8 and <=7.2 versions of gdbserver do not support such
automatic executable detection.
The following versions of gdbserver support it:
- Upstream version of gdbserver (unsupported) 7.10 or later
- Red Hat Developer Toolset (DTS) version of gdbserver from DTS 4.0 or
later (only on x86_64)
- RHEL-7.3 versions of gdbserver (on any architecture)
0xffffffff8100c065 in machine_idle (cpu=cpu@entry=0) at
../i386/i386at/model_dep.c:227
227  asm volatile ("hlt" : : : "memory");
(gdb) bt
#0  0xffffffff8100c065 in machine_idle (cpu=cpu@entry=0) at
../i386/i386at/model_dep.c:227
#1  0xffffffff81019737 in idle_thread_continue () at ../kern/sched_prim.c:1658
#2  0xffffffff81038b8c in Thread_continue () at ../x86_64/cswitch.S:104
#3  0xffffffffbf11ca88 in ?? ()
#4  0xffffffff81018db0 in ?? () at ../kern/sched_prim.c:924
#5  0xffffffffbf117fb8 in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) info thread
  Id   Target Id                    Frame
* 1    Thread 1.1 (CPU#0 [halted ]) 0xffffffff8100c065 in machine_idle
(cpu=cpu@entry=0) at ../i386/i386at/model_dep.c:227
(gdb)

> Did you enable kdb? I noticed that the prompt is different in the two
> cases... however on my setup it seems to work.

I haven't, at least not intentionally. My configure invocation was:

$ ../configure --prefix=/home/sergey/dev/crosshurd64 --host=x86_64-gnu
--disable-user32

I've no idea how to use kdb anyway, and why it is even needed when GDB
remote exists. (Maybe it's helpful for running on physical hardware?)

Sergey