IRC channel logs

<almuhs>hi. I'm trying to create a Rust binding for libtrivfs, and I need the mach.h header. Do you know where is it stored?

<youpi>$ dpkg -S mach/mach.h

<youpi>libc0.3-dev:hurd-amd64: /usr/include/mach/mach.h

<almuhs>thanks

<damo22>rump_init() crashes by itself with gcc -static -Wall -g -D_FILE_OFFSET_BITS=64 test-rumpusb.c -o test-rumpusb -Wl,--whole-archive -lrump_pic -lrumpuser_pic -lrumpdev_pic -lrumpdev_usb_pic -lrumpdev_pci_usbhc_pic -lrumpdev_pci_pic -lrumpvfs_pic -lrumpvfs_nofifofs_pic -Wl,--no-whole-archive -lpthread -ldl -lpciaccess -lirqhelp

<damo22>i need to compile with symbols to get a backtrace

<damo22>is it DEB_BUILD_OPTS=nostrip ?

<youpi>no, that's the contrary

<youpi>you want the hurd-dbg package

<damo22>no i mean for librump

<youpi>or hurd-dbgsym actually

<youpi>ah

<damo22>because rump is statically linked

<youpi>symbols in statically-linked libraries are a problem indeed

<youpi>you'll indeed want to build *both* rumpkernel and hurd with DEB_BUILD_OPTIONS=nostrip

<youpi>(hurd after installing the just-built rumpkernel of course)

<damo22>hmm maybe i will fix the dynamic symbol linkage issue first

<damo22>then i can just use the dbgsym packages

<damo22>does RTLD_LAZY | RTLD_GLOBAL get used by ld.so?

<youpi>sure

<youpi>AFAIK we have really no difference with the linux ld.so

<youpi>we only do not support the auxv and such which require kernel support

<damo22>the rump_allserver program uses dlopen

<youpi>(kernel support on linux)

<damo22>i think it preloads the .so files

<youpi>possibly the ld.so details vary between bsd and linux

<youpi>but normally RTLD_GLOBAL should take its effect so symbols show up

<damo22>what is the purpose of -Wl,--whole-archive and does its requirement cause a problem for dynamic linking option?

<youpi>that's only for static linking

<youpi>actually, for linking in a static library

<damo22>is that to stop symbols being dropped at link time?

<damo22>that are unused for example

<youpi>I don't remember how the rumpkernel build works, but if it uses it to build the .so, that might be needed indeed, to make sure everything is there

<youpi>yes

<damo22>but how do i link dynamically without losing symbols?

<youpi>? you don't

<youpi>gcc *.o -o libfoo.so

<youpi>you don't lose any symbol

<damo22>ok

<youpi>gcc foo.o libbar.a -o libfoo.so

<youpi>you might lose

<damo22>aha

<youpi>if you add -Wl,--whole-archive you don't

<damo22>got it

<youpi>(need to add that before the libbar.a)

<damo22>aha! i found something

<damo22>some of the libs are completely droppe

<damo22>d

<youpi>can't be good :)

<damo22>is there a linker option to force dynamic linkage of a lib even if all symbols are missing?

<youpi>ah, that's -Wl,--no-as-needed

<youpi>indeed, as-needed by default is new on GNU systems

<youpi>probably bsd doesn't do it by default

<damo22>fixewd

<damo22>fixed

<damo22>-rwxrwxr-x 1 demo demo 6760 Jul 1 18:35 test-rumpusb

<damo22>and it crashes probing usb

<youpi>nice! that'll make working on rump quite simpler :)

<damo22>yeah

<damo22>i'll do some digging and then clean up a patch for rumpdisk in hurd

<damo22>heh only 4.5M unacked irqs

<damo22>looks like it segfaulted in glibc

<damo22> https://paste.debian.net/plainh/c21646fe

<damo22>clock_nanosleep syscall?

<youpi>there is no pointer there

<youpi>possibly gdb is not actually getting the right thread id for the segfault

<youpi>it might be useful to set debug_all_traps_with_kdb in the kernel to get the real backtrace leading to this crash

<damo22>[ 1.7400050] ugen0 at uhub0 port 1

<damo22>[ 1.7400050] ugen0: QEMU (0x46f4) QEMU USB HARDDRIVE (0x0001), rev 3.00/0.00,

<damo22>addr 1

<damo22>kernel: Page fault (14), code=4

<damo22>Stopped at 0x1183c97: movl 0x24(%eax),%eax

<damo22>>>>>> user space <<<<<

<damo22>0x1183c97(11cd5c0,0,0,0,1184129)

<damo22>0x11a46cb(2007a800,2007ae00,a802c2c,10cd06e,2001edc0)

<damo22>...

<youpi>that rather looks like thread 19 in your paste above

<youpi>it was indeed the most probable candidate for a segfault :)

<damo22>i get different results every run

<damo22>i need to capture the backtrace with kdb catching the traps

<damo22>but when i return from kdb it registers the enter key

<damo22>so gdb continues

<damo22>and thus i cant capture the backtrace

<damo22>ok i can use serial console as well

<youpi>you don't need kdb any more

<youpi>you know that it's the rumpuser_mutex_spin_p which is faulty

<damo22> https://paste.debian.net/plainh/6bdab721

<youpi>you're missing the rump -dbgsym packages

<damo22>i installed those i thought

<youpi>(gdb) info sharedlibrary

<youpi>0x0000000101055b00 0x000000010105c816 Yes (*) /lib/librumpuser.so.0

<youpi>(*): Shared library is missing debugging information.

<youpi>you can check that

<youpi>at worse you can rebuild rump with DEB_BUILD_OPTIONS=nostrip

<youpi>but it's odd that the debugging symbols can't be loaded

<youpi>the file doesn't have with debug_info

<youpi>possibly the rump build doesn't actually pass -g?

<youpi>(possibly -g makes the build way larger)

<damo22>hmm

<youpi>(the file: in librump0-dbgsym)

<damo22>Thread 19 (Thread 3014.19):

<damo22>#0 0x01183c97 in rumpuser_mutex_spin_p () from /lib/librumpuser.so.0

<damo22>#1 0x0111ac6d in rumpns_mutex_spin_enter () from /lib/librump.so.0

<damo22>#2 0x011d541c in rumpns_xhci_intr () from /lib/librumpdev_pci_usbhc.so.0

<damo22>#3 0x0120c7c1 in ?? () from /lib/librumpdev_pci.so.0

<damo22>#4 0x012c2f8a in ?? () from /lib/i386-gnu/libirqhelp.so.0.3

<damo22>that is obvious where it called the mutex

<youpi>you can already try to look in rumpns_xhci_intr yes

<damo22>AHA there is UP locking and SMP locking

<damo22>when running with RUMP_NCPU=1 and compiled with SMP locking, it fails for some reason

<damo22>but how does that not affect rumpdisk?

<damo22>maybe it does! maybe that is why we see problems on smp

<damo22>[ 1.7900050] sd0: 107 MB, 218 cyl, 16 head, 63 sec, 512 bytes/sect x 220352 sectors

<damo22>opened sd0

<damo22>[ 1.8200050] rump kernel halting...

<azeem>the PostgreSQL build failures just got fixes upstream: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=29213636e6cddcb7b2c877bff8cb9ba470d392db and https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=1fd772d192909a4f0e1ce88ebc72c8c43b81b025

<azeem>oh nice, and even back-patched so all the live release branches should work again

<youpi>nice ):

<youpi>:)

<azeem>youpi: Tom Lane wrote in his commit comment "X/Open requires at least [IOV_MAX of] 16. (GNU Hurd apparently feel that they're not bound by X/Open, because they don't define this symbol at all.)"

<youpi>X/Open is very clear about such things

<youpi>IOV_MAX is optional

<youpi>and if not defined, yes the minimum is 16

<youpi>_XOPEN_IOV_MAX indeed is 16, as it should be

<youpi>(the minimum value of IOV_MAX, if defined)

<youpi> {IOV_MAX}

<youpi> ^[XSI] [O

<youpi> Maximum number of iovec structures that one process has available for use with readv() or writev().

<youpi> Minimum Acceptable Value: {_XOPEN_IOV_MAX} [O

<youpi>in section "Runtime Invariant Values (Possibly Indeterminate)"

<youpi>A definition of one of the symbolic constants in the following list shall be omitted from <limits.h> on specific

<youpi> implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified.

<youpi>I guess I'll just copy/paste that in the FOO_MAX faq entry

<azeem>right, I think this last sentence with "shall be ommitted" was cited by another hacker who wanted to take a look, but Tom beat him to it

IRC channel logs

2025-07-01.log