Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le dim. 28 mai 2023 13:32:12 +0300, a ecrit:
> Hello!
> 
> On Sun, May 28, 2023 at 12:13 AM Samuel Thibault
> <samuel.thibault@gnu.org> wrote:
> > > 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.
> > I commented the assert for now, and got a shell :D
> 
> You mean interactive bash works? \o/

Yes.

> And -- I assume you're using the full Hurd console?

No, I'm just on the mach console, for the debootstrap --second-stage
step.

> The port error is interesting; 82650 is clearly not a port name, so
> it's not a port use-after-free / double free, it's some bad/invalid
> memory. Hmm. Is something overwriting our TCB?

That could be. That could also explain the issues I'm getting with stack
protection.

> Do you think this is happening after running a signal / RPC
> interruption? Or after a timeout? Is there any easy way to reproduce
> this?

You can trap on the mach_port_deallocate warning case, or even in kdb
by setting mach_port_deallocate_debug to TRUE.

> It all "just works" nicely on a full distro, GDB even loads (or
> down-loads, with debuginfod)

We'll probably want to port gdb soon.

> What was the failing stack protector on, this time? It makes sense
> that thread_set_state needs to be built without a stack protector,
> compared to i386, because we now use it in early startup, whereas we
> didn't on i386 -- but what could be a x86_64-specific issue with lwip?

ATM I'm seeing various issues, like __dir_lookup telling me it got its
stack smashed. Which probably rather means that the stack_guard gets
overwritten somehow.

We can however defer fixing that to after we get a base system that can
build glibc itself, so we can just run the glibc testsuite and fix tests
as they go.

> On Sun, May 28, 2023 at 5:20 AM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > If people want to play with it, I have updated the image on
> >
> > https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz
> >
> > of course, since the second stage of debootstrap doesn't work yet,
> > nothing is configured, so you have to configure everything by hand to
> > get almost anything to work. It has various .deb packages available in
> > /var/cache/apt/archives that can be unpacked with dpkg -i
> 
> Cool, thanks, I'll check it out -- and awesome work all around :)
> 
> More questions: has there been any news on getting official hurd-amd64
> Debian packages?

The hurd-amd64 repo is open on debian-ports. I'm waiting for an actual
ABI stabilization before uploading packages there, and a working build
system before asking for wanna-build and run the buildd.

> And on that note, any news about the Rust GSoC project? Wasn't there
> supposed to be a community bonding period?

It started, yes. Vedant found most of its way already thanks to
wiki/faqs etc.

> Also, what do we do about [1][2]?
> 
> [1]: https://mail.gnu.org/archive/html/bug-hurd/2023-05/msg00287.html
> [2]: https://mail.gnu.org/archive/html/bug-hurd/2023-05/msg00288.html

That's basically part of the ABI step mentioned above :)

If people could help with reviewing the changes, that'd spare me time...

Samuel