IRC channel logs
2024-04-01.log
back to list of logs
<almuhs>/home/pruebas/rumpkernel-0~20211031+repack/pci-userspace/src-gnu/pci_user-gnu.c:551:15: error: implicit declaration of function 'vm_pages_phys' [-Werror=implicit-function-declaration] <almuhs> 551 | ret = vm_pages_phys (master_host, tp, vaddr, PAGE_SIZE, &paddrp, &count); <youpi>Pellescours: the patch already adds #include "gnumach_U.h" <youpi>almuhs: you probably want to check with find . -name gnumach_U.h that it did get generated <youpi>and that it does contain the additional declaration <youpi>(but again, you can as well just drop the patch, it's only an optimization...) <almuhs>it's not a test error, it's a compilation error <youpi>? I didn't say it was a test error <almuhs>yesterday i removed the patch but the error appeared anyway <youpi>had you de-applied the patch before removing it from the series? <youpi>the presence of "vm_pages_phys" in the source can only mean that the patch was not de-applide <youpi>(03:18:40) youpi: you can quilt pop the vm_pages_phys.diff patch <almuhs>oh, i only moved the file out of the directory <youpi>at some point you need to get acquainted with finding such answers by yourself <almuhs>i didn't undertood that "quilt pop" is <youpi>that's what I mean: then look it up in the documentation <youpi>you'll always get stuck in all kinds of situations if you don't get acquainted with the man reflex <Pellescours>patching the source tree is part of the build process of a package in debian. You have the source, a series of patches and before compiling, patches are applied. <almuhs>if i don't understand what is (even if this is a command, or an action...) i don't know what search <youpi>the unknown words in my sentences were quilt and pop <youpi>man pop doesn't produce any answer <youpi>really, it's an important thing: we cannot spend all our time explaining what is already expained in manpages <almuhs>there are not any page in man for quilt <youpi>quilt: /usr/share/man/man1/quilt.1.gz <almuhs>Ninguna entrada del manual para quilt <youpi>bad distro, change distro... <youpi>do you have the quilt package installed ? <Pellescours>youpi: when a package is build, are the build logs kept somewhere? I want to see a build logs (of test) of python12 package <youpi>Pellescours: not by default, no <almuhs>notice that i never had create a deb before <youpi>Pellescours: but there are archives of the package builds on buildd.debian.org <almuhs>Patch ../patches/vm_pages_phys.diff is not applied <Pellescours>ok, because I’m compiling python3.12 (non debian image, from cross-hurd bootstraped VM) and I can see a test that fails (test_json). It’s not a blocker to build python but I want to know if debian also has this problem. <youpi>otherwise quilt doesn't find .pc/ <youpi>(root of the build tree, where debian/ is) <almuhs>pruebas@debian-hurd:~/rumpkernel-0~20211031+repack$ quilt pop vm_pages_phys.diff <youpi>Pellescours: then you can indeed go to buildd.debian.org/python3.12 <youpi>you can use "quilt applied" to check what's actually applied <youpi>also "ls .pc/" to make sure what's happening <almuhs>pruebas@debian-hurd:~/rumpkernel-0~20211031+repack$ quilt applied <almuhs>debian/patches/piixide-rump.diff <almuhs>debian/patches/ahcisata-rump.diff <youpi>and "quilt series" to make sure it is reading debian/patches/series <almuhs>debian/patches/busspaceunmap-rump.diff <almuhs>debian/patches/memory-range.diff <almuhs>debian/patches/rumpuser-rng-debug.diff <almuhs>debian/patches/netbsd-build.diff <almuhs>debian/patches/no-virtio-rump.diff <almuhs>debian/patches/pci-userspace-rump.diff <almuhs>debian/patches/rumpuser-evcnt.diff <youpi>one thing: if you have removed vm_pages_phys.diff from debian/patches/series by hand, quilt will be confused <almuhs>debian/patches/vm_allocate_contiguous_align <almuhs>debian/patches/vm_pages_phys.diff <youpi>so you possibly need to re-introduce it there for quilt not to be confused <youpi>quilt pop vm_pages_phys.diff doesn't mean what you want <youpi>see manpage, it means to pop up to vm_pages_phys.diff, but not including <Pellescours>And when I tried to compile python3.12 on my debian VM, it hanged. <almuhs>Removing patch debian/patches/vm_pages_phys.diff <almuhs>pruebas@debian-hurd:~/rumpkernel-0~20211031+repack$ quilt pop <almuhs>Removing patch debian/patches/vm_pages_phys.diff <almuhs>Restoring pci-userspace/src-gnu/Makefile.inc <almuhs>Restoring pci-userspace/src-gnu/pci_user-gnu.c <youpi>and then you can comment it from debian/patches/series <youpi>so dpkg-buildpackage doesn't re-apply it <youpi>just comment the line in the series file <youpi>that'll be enough, and easy to revert if needed <youpi>note that you have learnt about quilt, that's a very useful thing <youpi>while it's compiling, read the manpage, it's a very convenient tool <almuhs>ok, now there are not an compilation error in this. But there are compilation errors in my code :-[. Some type incompatibilty in prints <almuhs>fuck. The VM keeps freezed during the compilation <almuhs>I put 4G, but in 32-bit the VM don't reach that size <youpi>sure, but 3G is better than 2G :) <youpi>otherwise qemu puts 2G memory beyond 4G <youpi>by asking for 3G, you have it all under 4G <almuhs>same. free -h show 2 GiB in total <youpi>possibly that's because you use some disk controller that takes some adressing space below 4G <youpi>does it get to fill before the VM freezes? <youpi>are you using rumpdisk while building? <youpi>perhaps better not use it while building, since it hogs memory and the swapping might not be working with rumpdisk <almuhs>i'm trying to change to IDE to use gnumach's IDE driver, but the disk is detected as SATA <Pellescours>is it a problem to use 4G with PAE? I just tried and free see 4G <youpi>rumpdisk is not completely ready for that <youpi>and the gnumach drivers are not at all <youpi>possibly the linux glue and rumpdisk glue do the pingpong <Pellescours>Ah I see so it works now because It use less that 1GiB, but if I stress it a bit I can have issues okay <youpi>though normally the allocator allocates highest whenever possible <youpi>so in principle you already hit the worstcase <youpi>still, that loads binaries from the disk <almuhs>i'm modifying my qemu script to change disk to IDE, but gnumach continues detecting as SATA <Pellescours>by default (disk with no option nor special driver) qemu put disk in IDE <almuhs>OPTIONS="-s -device ahci,id=ahci1 \ <almuhs> -drive id=root,if=none,media=disk,format=raw,file=$FILE \ <almuhs> -drive id=cd,if=none,file=$CDROM,media=cdrom \ <almuhs> -device ide-cd,drive=cd,bus=ahci1.2 \ <almuhs> -netdev user,id=net1,net=192.168.76.0/24,dhcpstart=192.168.76.5,hostfwd=tcp:127.0.0.1:2222-:22 \ <Pellescours>I just use "-drive format=raw,cache=writeback,file=hd.img" for the disk and it’s IDE <almuhs>yes, i set AHCI for rumpkernel, so now I'm undone this change <Pellescours>don’t forget to update fstab and grub boot command line <almuhs>yes, i'm trying to change grub boot command line, removing noide and replacing wd0 by hd0 <almuhs>changed the script, but the disk continues showing as SATA <almuhs> -drive format=raw,cache=writeback,file=$FILE \ <almuhs> -netdev user,id=net1,net=192.168.76.0/24,dhcpstart=192.168.76.5,hostfwd=tcp:127.0.0.1:2222-:22 \ <almuhs>maybe it's necessary to reinstall to change disk to IDE <Pellescours>no need to reinstall, I used to switch from rumpdisk to IDE gnumach often <almuhs>but i need to sleep. Tomorrow i will continue <damo22>i didnt have any problem compiling rumpkernel debian package using rumpdisk to drive the disk <Pellescours>when you start the gnumach compiler is it "normal" to have "Bad frame pointer: ..."? Does this show a bug or is it expected in some cases? <damo22>what command did you run to get that error? <damo22>maybe you are running a distro gnumach? <Pellescours>I have it when I compile python, I start the debugger at the middle of compilation and sometimes I get this message <Pellescours>I’m running on a self build gnumach but it’s written >>>>> user space <<<<<< <youpi>Pellescours: see about -fno-omit-frame-pointer <youpi>we build glibc and hurd with it, but the rest of debian we don't <youpi>it's questioned whether the whole debian (not only hurd) should be built with it <youpi>on archs that have a lot of registers, it wouldn't hurt, and fix such issue for stack unwinding <azert>Mach Port Translation Type Register? <azert69>So what is the use of MACH_MSG_TYPE_COPY_SEND_ONCE <solid_black>azert: to violate the entire idea/purpose of send-once rights? :D <solid_black>I was hoping that if the idea of copying send-once rights wasn't bonkers enough, at least MPTTR_EL1 would give it away ;) <azert40>solid_black: haha could be made a privileged operation. That can be achieved by opening a specific device. Root should be allowed to do everything <azert40>MACH_MSG_TYPE_COPY_RECEIVE? Why not! <solid_black>yeah, but as I said in the commit message, that's not easily implementable, since Mach relies on there only being a single receive right in a number of places <Pellescours>I made progress with my compilation of python that make hurd freeze completely <Pellescours>1st when it freeze it’s during a step that use lto programm, then when it freeze if I type characters on the console, nothing is displayed but I can full the gnumach keyboard buffer (after some number of types, a message is displayed in the gnumach console) <solid_black>so can you interrupt it in GDB and see what's going on? <Pellescours>Finally, and probably the most interresting place. I compile during more than 5 hours, again and again (in a loop) python and no hang, it was when I enabled the kernel debugger <Pellescours>I wanted to enable kdb to be able to debug at the hang time <solid_black>so, build without KDB, and use GDB to debug the hang <Pellescours>how can I use gdb to debug it? I mean to compile I run make that will launch multiple commands. Should I compile until the culprit step then stop and start it manually with gdb? <solid_black>I assume you're running GNU/Hurd in qemu; qemu has the '-s' switch to enable a built-in GDB server (aka gdbstub; you can also type something in the qemu monitor to enable it dynamically instead of passing a switch) <solid_black>from there, you can run/pause/step, view stacks and variables and memory, etc <Pellescours>solid_black: were the security issue you found in gnumach patched? I remember a privilege escalation one month ago <solid_black>nobody seems interested enough in 0-day gnumach issues to even ask me what the issue was <solid_black>(I described v1 of the exploit (which was already patched by Samuel, so it's effectively public) to Pellescours in PM) <Pellescours>I tink I’m in a situation where the bug was triggered <Pellescours>0xc1017c3e in machine_idle (cpu=0) at ../i386/i386at/model_dep.c:242 <Pellescours>#0 0xc1017c3e in machine_idle (cpu=0) at ../i386/i386at/model_dep.c:242 <Pellescours>#1 0xc103917a in idle_thread_continue () at ../kern/sched_prim.c:1680 <Pellescours>#2 0xc103857a in thread_continue (old_thread=0xf588ee60) at ../kern/sched_prim.c:845 <Pellescours>#3 0xc10497dd in Thread_continue () at ../i386/i386/cswitch.S:96 <Pellescours>What does the console not responding to input ("kbd is full" message is printed if I type a lot of keys) <solid_black>the translator sitting on /dev/console is supposed to be doing that <azert>I wonder for what use cases people at Apple implemented MACH_MSG_TYPE_COPY_RECEIVE as well as the DISPOSE message types <solid_black>I always thought the DISPOSE port dispositions would destroy your right, and the receiver just wouldn't get anything in its place <solid_black>and now that I'm looking, I don't even see the DISPOSE dispositions being implemented anywhere in XNU <Pellescours>I discovered that compiling gnumach with or without debugger doesn’t change anything. For my other tests I was running with debugger enabled, I was just not aware of that as the debugger didn’t started when I typed ctrl+alt+d (as console as not consumming my keys) <solid_black>Pellescours: good, then enable KDB and you should be able to see what tasks/threads are running from there <Pellescours>I need to redo it but I think I was able to do list task and list thread just before the hang (I typed continue and then hang) <Pellescours>There is 7 tasks but not of them seems to be about compilation <solid_black>so now that it's hanging, can't you bring up the debugger again? <solid_black>pretty sure machine_idle must run with interrupts unmasked <solid_black>let's see if you can forcefully enter KDB from GDB by the way <solid_black>though that'd probably fail because it won't find the interrupt handler stackframe, don't do that <Pellescours>I restarted the build and started kdb at the step that hang but before the hang <Pellescours>I see lto1 process with 2 threads: "0 (...) R....F" and "1 (...).W.O.. (mach_msg_continue) 0" <Pellescours>but when I started the debugger, I got a lot of messages "no memory is assigned at address ..." and the last line is 0x0() <azert>I’m not sure and I don’t know either. But out of my imagination copying receive rights might be useful for sending them to sandboxed processes that cannot make any port for sandboxing reasons <azert>But I think gnumach doesn’t support these kind of tasks <Pellescours>I can see a rumpdisk thread in exception_raise_continue, one in ext2fs in vm_fault_continue <Pellescours>otherwise there is a lot of threads in mach_msg_continue or mach_msg_receive_continue