IRC channel logs

<azert>Gooberpatrol66: I tried getting that working on a A64-OLinuXino open source board

<azert>gnumach had some issues, it was using not existing memory

<azert>But many other things such as uarts were easy to implement

<azert>In general, the glibc part of aarch64 has not been upstreamed, although it was near ready

<azert>So it is going to possibly be lost

<azert>Gnumach was nowhere near ready

<azert>I’m personally looking forward for large models on ai coprocessors, those might be a real revolution in the way hardware is designed

<azert>Also the internet might change its shape

<azert>tbh, internet has been already nuked by large language models. the part where they come to the rescue to be useful is yet to arrive

<azert>I’d love to have a fully working phone without screen that can store information on my behalf and retrieve it for me efficiently. To my surprise, that’s not happening

<camm>when using any of the images at https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/?C=M;O=D under kvm as instructed in the README, most any simple operation, e.g. apt-get, followedby a reboot leaves the system broken, i.e. acpi crash, no network, no login promt, etc.

<camm>Amy instructions for a basically stable test build hurd-amd64 environment?

<youpi>camm: maybe we just need to upgrade the image, there have been various fixes there

<gnucode>morning friends

<camm>youpi: thanks so much -- wondering if there is a simpler route ala debootstrap/qemu-??-static

<youpi>crosshurd probably sorta works

<youpi>mmdeboostrap should also be working

<youpi>the second stage has to be done natively, though

<camm>thanks again -- pointer url to sample instructions?

<youpi>it was mentioned on the debian-hurd mailing list

<youpi>waiting for somebody to take the time to write down proper instructions

<camm>thanks

<camm>separately, a few questions on mmap

<camm>if mremap shrinks a map, expanding again -> ENOMEM

<camm>mmap apparently does not consider existing memory when returning -1 or not -- very extreme overcommit appears standard

<camm>apparently no MAP_STACK nor growsdown flags

<gnucode>camm You are trying to get the Hurd to run on AArch64 right? Good luck!

<camm>youpi: No, actually just found a way to port GCL

<youpi>camm: it seems glibc/sysdeps/mach/hurd/mremap.c does look at shrink/expand existing allocation

<youpi>possibly your case is not support, investigation welcome

<camm>So it should work the way it does on Linux, at least wrt mremap shrink/expand?

<camm>Current working on hurd-i386, mmap grow only starting at &_end, after munmap the sbrk space at 0x20000000

<youpi>"munmap the sbrk space" ?

<camm>Probably mistermed this. Hurd places a fixed sbrk(0) start at 0x20000000 on i386, leaving a hole wrt &_end that is problematic. Explicit mmap at &_end will work, but only 300M available unless we move that map our of the way.

<youpi>can't you mmap after the heap?

<youpi>the remap code comments talk about shrink/expand, so a priori at least some cases are supported

<youpi>possibly some aren't, but could be, investigation welcome

<camm>Not if I need to unexec a contiguous .data section containing code adjacent to .text

<camm>Hurd used to start sbrk at &_end as was traditional, when this changed the port broke. sbrk is not POSIX now anyway so I am emulating via mmap

<camm>Will try to get a mremap bug report when this is stabilized.

<camm>Would like to get amd64 working first as I presume that is the future.

<youpi>it is

<youpi>I don't see the relation with .data

<youpi>mmaping further away, after the heap, would precisely avoid conflicting with .data

<camm>the standardly linked executable allocates new memory and places code in it, then dumps into a new .data section adjacent to the old one. .text and .data.... heap are contiguous.

<camm>An alternate workaround might be as you suggest mapping somewhere else, and translating actuall addresses with LMA/VMA in the executable, but I would prefer to avoid this complication

<youpi>again, I don't understand

<camm>The 32bit systems will need every bit of the 3G or so heap theoretically available.

<youpi>code+data is early in the space

<youpi>then you have a hole

<youpi>then you have the heap

<youpi>then you have a lot of room for mmap

<youpi>then you have the stack

<youpi>you can put the additional data in the hole before the heap

<camm>Actually it appears the stack is below .text

<camm>But yes in general your description is right.

<camm>unexec as currently written cannot accomodate holes in the working heap, and dumps the contiguous working data into the executable.

<camm>It surely could be rewritten to skip over holes, but this can be complex

<camm>Without the unmap, there will at least be a hole at 0x20000000 that needs skipping over in a potential 3Gb heap

<camm>Is there a problem with unmapping the space? Seems to work well.

<camm>Anyway if 64bit is the future this is kind of moot....

<camm>In general one does want to keep code in new .data as close to .text as possible.

<gnucode1>sneek later tell youpi thanks

<sneek>Will do.

IRC channel logs

2025-03-14.log