Re: 64bit startup

[Samuel Thibault]

Samuel Thibault, le sam. 27 mai 2023 12:16:50 +0200, a ecrit:
> Sergey Bugaev, le ven. 26 mai 2023 17:31:40 +0300, a ecrit:
> > On Fri, May 26, 2023 at 2:15 PM Samuel Thibault <samuel.thibault@gnu.org> 
> > wrote:
> > > It does load, but stays stuck when starting ext2fs:
> > >
> > >    start ext2fs:
> > 
> > Yes, I can reproduce this with your build of ext2fs.static
> > 
> > Unfortunately there are no symbols (maybe you could teach me how to
> > fetch and load separate debuginfo into gdb?), but it's crashing on:
> > 
> >    0x000000000055cd00: push   %rbp
> >    0x000000000055cd01: mov    %esi,%eax
> >    0x000000000055cd03: mov    %rdx,%rsi
> >    0x000000000055cd06: mov    %rsp,%rbp
> >    0x000000000055cd09: push   %r13
> >    0x000000000055cd0b: push   %r12
> >    0x000000000055cd0d: push   %rbx
> >    0x000000000055cd0e: sub    $0x1048,%rsp
> > => 0x000000000055cd15: mov    %fs:0x28,%rdx
> > 
> > (gdb) p $fs_base
> > $2 = 0
> > 
> > %fs:0x28 is tcb->stack_guard. The function is thread_set_state, I
> > believe -- it's trying to set this very fs_base to the
> > __init1_tcbhead. Clearly it gets built with the stack guard in
> > your/Debian build, but not in mine or Flavio's.
> 
> --enable-stack-protector=strong has been a default in debian for a long
> time indeed. I guess we just need to add more of 
> 
> mach/Makefile:CFLAGS-mach_init.o = $(no-stack-protector)
> 
> for now I'll disable the protector by hand to get something working.

Thanks for having investigated!

Disabling the protector indeed helped a lot :) Packages are getting
rebuilt (with debugging information, this time...), but I could already
build some debian initrd image:

https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz

(500MB initrd size seems too much for the current kernel virtual memory
layout, we should probably try to extend gnumach's kernel pmap size, but
at least 300MB seems to be working for now).

It booted up fine until:

start ext2fs: Hurd server bootstrap: ext2fs[device:rd0] exec startup proc auth.
/usr/libexec/console-run: /dev/console: Read-only file system

task /bin/bash(1) decreasing a bogus port 82650 by 1, most probably a bug.
bash: ../sysdeps/mach/hurd/mig-reply.c:84: __mig_dealloc_reply_port: Unexpected 
error: (os/kern) invalid name.

the console warning is expected, we get the same with hurd-i386. But the
bash port deallocation is bogus indeed.

Samuel