IRC channel logs

<diegonc>has anybody written a guide for doing rump stuff?

<diegonc>I'm trying the tutorial[1] but it doesn't compile

<diegonc>[1] https://github.com/rumpkernel/wiki/wiki/Tutorial%3A-Getting-Started

<damo22>sneek: later tell diegonc librump is already compiled on debian, you dont need to compile anything, just write a test program and link it. See rumpdisk/block-rump.c and the Makefile for details

<sneek>Okay.

<damo22>rrq: do you know which packages i need for a working x86_64-linux-gnu-gcc that supports -m32 and static libgcc

<damo22>on devuan

<damo22>i think i have an incompatible set of packages installed

<damo22>/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/14/libgcc.a when searching for -lgcc

<damo22>/usr/bin/ld: cannot find -lgcc: No such file or directory

<damo22>/usr/bin/ld: have you installed the static version of the gcc library ?

<damo22>im not sure if i need multilib, or cross or what

<youpi>that depends on the generation of devuan that you have

<youpi>recently it's in libgcc-14-dev-i386-cross

<damo22>ok interesting

<rrq>damo22: not sure

<rrq>noting gcc is devuan ported so it'd be whatever is in debian

<rrq>s/ported/forked/

<damo22>do i need gcc-x86-64-linux-gnux32

<rrq> https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=file&q=libgcc.a&x=submit

<youpi>x32 is a completely different thing

<youpi>it's really i386 that you want

<rrq>right, then e.g. lib64gcc-14-dev-i386-cross ?

<rrq>version 14.2.0-19cross1 in excalibur, and 14.3.0-14cross1 in freja and ceres

<rrq>(I'm just reading off pkginfo)

<solid_black>hello :)

<damo22>ok ive removed all my gcc toolchains, what packages should i install to get a working x86_64 toolchain with -m32 ability to compile and link static i386 binaries

<damo22>lib64gcc-14-dev-i386-cross gcc ?

<damo22>or gcc-multilib

<damo22>it seems the right libraries are not in the path when -m32 is passed

<damo22>or i have the wrong toolchain installed

<damo22>it works on fedora 44 for example, with riscv64

<damo22>i want the i386 libgcc to be used when -m32 is used on the 64 bit toolchain

<rrq>looks like gcc-14-x86-64-linux-gnux32 doesn't depend on lib64gcc-14-dev-i386-cross gcc but rather grings libgcc-14-dev-x32-cross

<damo22>x32 is something else apparently

<rrq>yes, and I think lib64gcc-14-dev-i386-cross is the one containig libgcc.a

<damo22>yeah but the paths are not configured for gcc-14 to use the gcc-cross libs

<rrq>and you are running this on an emulated md64 ?

<damo22>no this is just on your CI box

<rrq>hmm that can run i386 via binfmt emulation

<damo22>i dont want to run the binary

<damo22>just compile it

<rrq>yeah, I meant to install i386 gcc compiler

<rrq>run the compier in emulation

<damo22>no need

<damo22>the CI script i wrote uses x86_64-linux-gnu-gcc -m32

<rrq>:) ok. I thought that would be easier than cross compiling

<damo22>its not really cross compiling, the compiler has 32 bit support

<damo22>it just needs libs

<rrq>you may need ld script to pick the right lib (?)

<rrq>(I'm not versed in cross compilation)

<damo22>yeah i shouldnt need to pass -L/path/to/32bit/libs to the toolchain, it should realise i am using -m32 and switch to i386 libs

<damo22>thats what it does on my riscv64 box

<damo22>is that what multilib support is all about?

<rrq>I prefer using binfmt and qenu-user-static which lets the processor seamlessly execute banires of different arch

<rrq>but I suppose it may need ain i386 chroot

<rrq>with gcc installed plus the static libggc.a

<rrq>so would be different workflow

<damo22>ok i fixed it by installing gcc-multilib

<damo22># x86_64-linux-gnu-gcc -m32 -static -nostartfiles -nolibc -ffreestanding test.c -o test

<damo22>/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 08049000

<rrq>-nolibc (?)

<rrq>should it be -stdlib ?

<rrq>I meant -nostdlib

<damo22>no, the tests dont have glibc

<damo22>okay the CI is working on both boxes now

<damo22>without needing to change the last commit

<damo22>why would there be an error running host_get_time64 on user32?

<damo22>its a struct of two int64_t

<youpi>possibly alignment mismatch

<youpi>or such details on the encoding

<damo22>diegonc: hi, have you worked on mig alignment issues before?

<diegonc>damo22: no, not relly :(

<sneek>Welcome back diegonc, you have 1 message!

<sneek>diegonc, damo22 says: librump is already compiled on debian, you dont need to compile anything, just write a test program and link it. See rumpdisk/block-rump.c and the Makefile for details

<diegonc>do you think the failing test is an aligment issue?

<diegonc>damo22: oh, I thought rump needed to be recompile to add drivers and such. I'll have a look at rumpdisk

<diegonc>*recompiled

<damo22>you can add more drivers to rump but that requires fixing makefiles in netbsd

<damo22>but if you want to test rump with what we have existing you dont need to recompile it

<damo22>the failing test is most likely an alignment issue according to y oupi

<diegonc>I just saw the logs. how big is a host_t in user32? maybe some padding is missing in between it and the time struct

<damo22>i dont know

<damo22>it has two ipc_ports

<damo22>maybe rpc_uintptr_t ip_protected_payload;

<damo22>has a different size on 32/64?

<damo22>is there an assumption that the host kernel bits is the same as the rpc?

<damo22>rpc_uintptr_t seems like a bad type

<youpi>it is needed

<youpi>when the ponter size is not the asme in kernel and user

<youpi>rpc_uintptr_t follows the userland ponter size

<youpi>since userland is not supposed to know whether kernel is 32 or 64

<solid_black>host_t is a mach_port_t in userland, always 32 bits

<solid_black>generally, Mach IPC / MIG is designed in such a way that it just works in user32, with no special considerations

<solid_black>the kernel should do all the translations

IRC channel logs

2026-06-26.log