IRC channel logs
2024-01-28.log
back to list of logs
<youpi>damo22: put a 1: jmp 1b to catch progression in the assembly code <youpi>and you'll be able to see the state <AlmuHS>damo22: to check the GDT, if you're using qemu, you can check it in the monitor <AlmuHS>cpu 1 and show registers, if i remember well <AlmuHS>but you might calculate the GDT hex value in the calculator to comparate with qemu <anatoly>solid_black: how many times does it build/re-build gcc? I counted 5 <damo22>that does not look right, but the address stored in %eax is 0x7132 which contains correct values <damo22>i did lgdt (%eax) <--- where %eax = 0x7132 <damo22> 0000000000007132: 0x71400017 0x00000000 0x00000000 0x00000000 <damo22> 0000000000007142: 0x00000000 0xffff0000 0x9a000000 0xffff00cf <damo22> 0000000000007152: 0x92000000 0x000000cf 0x00000000 0x00000000 <damo22> CS =0700 00007000 0000ffff 00009b00 <damo22> DS =0700 00007000 0000ffff 00009300 <damo22>i dont know how to read that CS segmentation <damo22>did it get set up by IPI with special segmentation? <damo22>GDT looks like its set to reset vector or something? <damo22>how do i tell lgdt with a 16 bit address? <damo22>maybe i didnt dereference the pointer... <damo22>is it possible the segmentation is already set up such that AP launches always with CS:0 as first address? <solid_black>anatoly: it's supposed to be 3 times for the corss-compiler, and one more time for native <solid_black>but fwiw, this is entirely a side effect of bootstrapping; we would only build gcc once on the native system <anatoly>solid_black: 4 is what I expect but as I said I could've miscounted it <solid_black>let's see if I can make glibc not require /bin/sh again <anatoly>so I've got ~500MB final container image, I will upload it as well as my change <solid_black>is that with only a compiler, or with all the pcakges built? <solid_black>also please wait, I'm about to upload my latest changes once I verify nothing new breaks <solid_black>do you happen to have an experience with debugging openrc bootup? <anatoly>the image contains compiler and the packages based on your last commit (up to grub) <anatoly>I'm wondering if splitting scripts/bootstrap.sh in towo phases (cross-compiler and base system) would make sense for better organisation of container images and CI <anatoly>For example add another argument to specify a phase when running the script <solid_black>we definetely wouldn't want to re-bootstrap the whole thing on every commit <solid_black>not sure if two-phase approach is the best solution for that thought <solid_black>maybe we just want a single persistent system that would just run scripts/bootstrap.sh, reusing the packages built on the previous run? <solid_black>as opposed to spawning a fresh container from the base image each time <anatoly>"we definetely wouldn't want to re-bootstrap the whole thing on every commit" - that's not the intended reason <anatoly>"as opposed to spawning a fresh container from the base image each time" - and it doesn't go against it <damo22>when i load the GDT, the CS changes! <anatoly>What I'm doing now is not targetting you, you have the packages from the previous runs, etc. I'm thining more about those who want to try to build their package or to rebuild base without waiting for cross-platform toolchain to build, it's not what they are interested in <solid_black>maybe we just need a separate script instead of bootstrap.sh <solid_black>which is what I am/was doing, but (IIUyouC) not that use case you're talking about <anatoly>Also building images/container in these two phases better suits CI <solid_black>so maybe we'd need a different script, one that would do something like what the loop at the end of bootstrap.sh does, but instead of using a hardcoded list of packages in a hardcoded order, the script would take a specific target package (or several), walk a tree of dependencies, figure out a build order, and do that <anatoly>We can rebuild the base without touching cross-compile image <solid_black>btw do you think it would be easier/better, instead of providing a CI image with a cross-compiler packages pre-built, we'd provide a (tempotary?) repo for x86_64 Alpine with patched abuild & prebuilt binutils-x86-hurd / gcc-x86-hurd / mig-x86-hurd? <anatoly>solid_black: I think this is a good idea but is it a show stopper now? <solid_black>so basically people would be able to add that repo to their system / container? <anatoly>solid_black: I think both things are right and useful. Someone might not mock around with containers <anatoly>I do really understand that containers are not useful that much on local machine further in development, it's for CI land <anatoly>But for now I feel it's useful if someone wants to try things quickly, no matter what they use, not waiting for build times <solid_black>it is surely useful for local development too; I don't run Alpine on my host, so I do this hacking in a container (and also in a VM) <solid_black>yes, providing a prebuilt toolchain one way or another is definitely a good idea <anatoly>Today I setup another machine (newere one) to re-build faster <solid_black>I must have broken something somewhere when rebasing :( <solid_black>apk refuses to install build dependecies for mig, some sort of conflict issue between gcc packages <solid_black>ah no, looks like it's just my system having a stale .makedepends-gcc package in /etc/apk/world (due to some badly interrupted abuild run?) <solid_black>anatoly: where are you planning to upload an image to? <youpi>damo22: without seeing your code it's hard to say anything useful <anatoly>solid_black: gitlab, I'm currently fighting gitlab's access keys thing, as usual <solid_black>I wonder if we could just dump a bunch of .apk-s (+APKINDEX) somewhere to serve as a temporary repo <youpi>damo22: all I can say is that AFAIK the AP boots in real mode, i.e. cs just contains the paragraph address <youpi>I don't know if the ipi sets that to 0 and ip to the address, or it sets cs to the paragraph and ip to 0, but gdb before the lgdt instruction will tell you for sure <youpi>one thing: in the current cpuboot.S code, we set ds to 0 before calling lgdt, so that the address given to lgdt is in the paragraph 0 <anatoly>solid_black: git lfs, maybe, although never tried <solid_black>(nitpicking, but you should not be putting each shell command into its own RUN; 'cause that generates a layer each time) <anatoly>solid_black: I know :-) but it's handy while playing and trying, I will condense instructions later <solid_black>hm, so this makes a new image with preinstalled patched abuild and all the prebuilt apks in ~/packages? <anatoly>Need better apk repository key setup as well. I'd guess someone would like to provide their name, etc. <anatoly>I guess I need to have separate repositories if I want to split cross-compiler from the rest of the base package <anatoly>so that a user can add volume to ~/packages to preserve packages and start building things <anatoly>Or wiil simply installing cross-compiler work? <solid_black>did you figure out whether abuild can itself rebuild dependencies as needed? <anatoly>-r is for "Install missing dependencies from system repository (using sudo)" <anatoly>this is very interesting. It seenms like -R|--recursive being proxied to abuild but it's not an argument it supports <anatoly>I can see recursive call to abuild form itself only for subpackages <solid_black>(this is a web UI to browse packages, search for files, etc) <solid_black>sneek: later tell anatoly: I've pushed my recent work, please try re-bootstrapping it