IRC channel logs
2023-01-28.log
back to list of logs
<stikonas>oriansj: I found a semi-usable way to disassemble stage0 binaries with objdump <stikonas>e.g. you can use "objdump -b binary -m i386:x86-64 -M intel -D hex1" <stikonas>it just disassembles everything including elf header <stikonas>but that's better than it not working at all <fossy>i've just made a PR to rework tmpdir because it was annoying me a lot <fossy>suprisingly an overall reduction in LOC <fossy>this does not change any checksums <fossy>note that the default is now not a tmpfs and that must be specified with --tmpfs <stikonas>and presumably tested with various modes? <fossy>it needs more testing before merge though. i havent covered every combination <fossy>but not every combination of options <stikonas>well, you probably can just test that it starts <stikonas>perhaps we can make it a bit more readable with pathlib instead of os but it's up to you <stikonas>and probably best not to mix into this PR <stikonas>fossy: how is GCC going? Any significant problems? <fossy>stikonas: xgcc (stage2) was having trouble locating crt*.o because it didn't know about /usr/lib/musl. instead of fixing that i'm going to wait for the triplet PR because GCC expects crt* to be there anyway <fossy>oh, btw, doras, can you please change /usr/lib/i386-linux-musl in #201 to /usr/lib/i386-unknown-linux-musl (becaue that's the triplet we use everywhere else and have all our tools configured with) <stikonas>though maybe it's also worth building just 1 stage of GCC 10? <fossy>i386-linux-musl is technically not correct for triplet anyway because its arch-vendor-system <fossy>stikonas: hm, quite possibly <stikonas>and then do full self-bootstrap build of GCC12 <fossy>i'd prefer to run the sanity checks of gcc10 (full bootstrap) at least once in dev environment, but we can disable it before merge <stikonas>we are not going to benefit much from rebuilding GCC10 with itself if we only build GCC12 <stikonas>we should get triplet merged first anyway <stikonas>fossy: and unrelated question raised by python PR <stikonas>where do we want to put readline (and ncurses)? <fossy>stikonas: i don't mind putting readline early because then bash can use readline <stikonas>but I think they both can link to ncurses <fossy>oh really? never realised that <stikonas>yes, there is lib/readline directory in the tarball <stikonas>but we build it without ncurses and I suspect that might be causing somewhat weird command line behaviour in qemu mode <fossy>yes, let's put it early then <stikonas>in sysc the order is less critical anyway <fossy>yeah, apart from the major toolchain stuff <stikonas>anyway, readline and ncurses is for a bit later <stikonas>right now I was doing a bit more stage0-posix-amd64 work <oriansj>stikonas: I find ndisasm (usually packaged with nasm) quite handy for disassembly of stage0-posix binaries. It also gives you the option to skip the elf header, which is quite handy. <stikonas>anyway, I'm now updating hex1_AMD64.hex0 to include new style defines <stikonas>and also making it a bit smaller (will cut 219 bytes) <stikonas>(just by using 8-bit jumps and cmp_al, instead of cmp_rax,) <doras>fossy: as far as I know the defacto standard for multiarch library paths is arch-kernel-system <sam_>the location of it is dependent <sam_>/usr/lib/${CHOST} is a debian thing i think <sam_>please don't look at what debian does for any of this <sam_>they're the odd ones out <fossy>my thoughts are that the triplet everywhere else in the system is i386-unknown-linux-gnu - why would /usr/lib/triplet be something different <fossy>debian also appears to use whatever strange triplet that is all throughout the system not just /usr/lib so at least it's consistent <fossy>sam_: what does gentoo do? does gentoo use /usr/lib/triplet at all? <doras>fossy: there's reasoning in that Debian page under "Why not use GNU triplets?" <fossy>i don't understand either of those two points - especially not for our purposes <doras>freedesktop-sdk (and therefore Flatpak apps) also use arch-kernel-system. <fossy>the different iX86's are different instruction sets, and particularly for live-bootstrap, the bootstrap does explicitly target i386 at least in early stages <fossy>i'm aware it doesn't work on i386 at the moment fully <fossy>but either way, i'm not happy with having an inconsistent triplet in the system - either /usr/lib/triplet needs to change to the current triplet, or all uses of the triplet need to change <doras>fossy: I guess it's mostly philosophical. <fossy>doras: yeah, it is philisophical largely, whatever the actual triplet is doesn't bother me too much, but having inconsistent triplets does bother me from a functional standpoint - eg, GCC expects that either the libc is in /usr/lib or /usr/lib/<triplet> - where triplet is what it is configured with <doras>Which OS uses arch-vendor-kernel-system? <fossy>void linux & alpine linux both appear to <doras>fossy: I don't mind using the GNU triplets as-is. <fossy>doras: Given that there's no real established standard in distributions (seems like there's only attempts to do so), let's just stick with the GNU triplet as is and make it /usr/lib/i386-unknown-linux-musl so we can get this PR shipped out. later we can revisit the triplet issue and make another atomic change <fossy>it's really easy to change these things in live-bootstrap, unlike most distributions <sam_>fossy: we do /usr/triplet <sam_>fossy: everything is under that for cross-compilation. for multilib, stuff is also under /usr/${CBUILD}/${CHOST} <fossy>sounds like everythings a bit of a mess and there's little standardization? <stikonas[m]>We definitely should keep chroot mode chained as otherwise it's not usable (sudo password expires unless you monitor your build). Maybe for bwrap mode it would be fine to split it and make rootfs.py call another bwrap command for sysc_image... <doras>stikonas: I suggest requiring rootfs.py itself to be called with sudo instead of individual commands within it. <doras>We're already calling sudo in 12 places in the code (and more in total for each bootstrap). We may as well just do it only once for the entire script. <doras>Only for the chroot mode, of coure. <doras>This would be similar to how package managers expect to be called with sudo for their operation. <doras>Those who worry about running random scripts with sudo should be using bwrap anyway. <stikonas[m]>That has some disadvantages, you'll end up with root owned files in your homedir <stikonas[m]>And in general I think people are moving away from running whole apps as root to use small polkit helpers <doras>Well, we end up with such files anyway at the moment. <doras>Another option would be to split the bootstrap preparation to one script and the part that actually starts it to another, with the second being run with sudo. <doras>i.e., create a small chroot-helper.py and use it to trigger the bootstrap. <doras>stikonas: this would be less disadvantageous, no? <doras>stikonas: no need, we could continue to use the existing logic for all preparation. <doras>While executing the external script with sudo of course. <doras>Then that script can have a two step bootstrap (sysa, sysc) with chroot being called in-between at the Python level. <doras>fossy: I'm running a few bootstraps to test the /usr/lib/i386-unknown-linux-musl change. I will likely update the PR later today. <doras>fossy, stikonas: I think the tmpdir rework broke qemu without --external-sources. <doras>It seems that this mode requires a disk image without filesystem and we no longer create one? <doras>Or... something else. It's a bit hard to follow that code :s <doras>The two first commits aren't actually related to the MR, but are small enough that it doesn't matter.