Re: 64bit startup

[Sergey Bugaev]

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/

And -- I assume you're using the full Hurd console?, not streamio on
Mach console like me?

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? Do you think this is
happening after running a signal / RPC interruption? Or after a
timeout? Is there any easy way to reproduce this? (now that you must
have disabled the assertion in your initrd-amd64.img)

On Sun, May 28, 2023 at 12:31 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> BTW it's as simple as
>
> symbol-file  
> ./usr/lib/debug/.build-id/3e/a2af77859e5cfd5c1b726d81f135bfbfb3d1f0.debug
>
> (the build id is visible in the `file binary` output)

Yes, I understand that much.

But I probably want to do add-symbol-file rather than just
symbol-file, to use multiple symbol files at the same time (say, one
for gnumach, one for /bin/bash, one for libc.so, one for
libpthread.so, one for ld.so, ...). And it wants the address of .text,
which I normally do provide -- when the .text and the debuginfo are in
the same binary. But with debuginfo being in a separate binary... I'm
not sure how this all is supposed to work. Is there still a .text in
the debuginfo ELF? (I think there is, but it's NOBITS?) What address
do I plug in?

It all "just works" nicely on a full distro, GDB even loads (or
down-loads, with debuginfod) the matching debuginfo files
automatically without me having to do anything. But now that I have to
do it manually, I'm unsure how it's supposed to work, and there are no
docs or explanations.

On Sun, May 28, 2023 at 04:34 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> And rumpdisk as well :)
>
> [   2.9500050] wd3 at atabus5 drive 0
> [   2.9500050] wd3: <QEMU HARDDISK>
> [   2.9500050] wd3: drive supports 16-sector PIO transfers, LBA48 addressing
> [   2.9500050] wd3: 50001 MB, 101589 cyl, 16 head, 63 sec, 512 bytes/sect x 
> 102402048 sectors
> [   2.9600050] wd3: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 
> (Ultra/100), NCQ (32 tags)
> [   2.9600050] wd3(ahcisata0:3:0): using PIO mode 4, DMA mode 2, Ultra-DMA 
> mode 5 (Ultra/100) (using DMA), NCQ (31 tags)
>
> and it seems to be working :D

Yay, this is so cool! You could make an attempt to boot off the rumpdisk then?

On Sun, May 28, 2023 at 05:20 AM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> > lwip seems to be crashing for now.
>
> After disabling stack-protector again,
>
> # ping -c 1 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=20.000 ms

🎉

So technically, if nano works, we could start working on that blog post :D

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?

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? I see there has been a response to the thread [0].

[0]: https://lists.debian.org/debian-hurd/2023/05/msg00031.html

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

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

Sergey