IRC channel logs

<oriansj>and it works on amd64 when built by tcc/gcc/clang

<Googulator>alright, M2-Planet is giving me a hard time

<Googulator>on amd64, 0xFFFFFFFF gets compiled to 0xFFFFFFFFFFFFFFFF

<Googulator>it wants to sign-extend everything that has the uppermost bit set

<Googulator>oriansj: any ideas?

<oriansj>hmm

<oriansj>so you only want 0xFFFFFFFF on 64bit systems

<Googulator>even 4294967295 becomes 2^64-1

<Googulator>yes, because I need to check 32-bit fields against an "all-ones" condition

<stikonas>Googulator: you shouldn't use 32-bit numbers in M2

<stikonas>generally anything over 31-bit would behave strange

<oriansj>make a function which returns uint32_t and inside of it put return ((0x7FFFFFFF << 1) | 0x1);

<stikonas>Googulator: this is why I do things like https://git.stikonas.eu/andrius/stage0-uefi/src/commit/90585802bc7d73a85876f9230f980b2cf46d977e/posix-runner/posix-runner.c#L15

<Googulator>figured out a way

<Googulator>#define BIT31 (1<<31)

<stikonas>well, any arithmetic operation would do...

<stikonas>I just used +

<Googulator>& then instead of writing 0xFFFFFFFF, write (0x7FFFFFFF & BIT31)

<stikonas>I was hitting this a lot on UEFI

<stikonas>as I had to use a lot of 32-bit numbers...

<stikonas>various GUIDs need themn

<stikonas>and also this syscall stuff with LSTAR register

<Googulator>meanwhile, successful Linux tar.xz extraction in Fiwix with the latest iteration!

<Googulator> https://gist.github.com/Googulator/5e326929cc972eee3584c8201513c95d

<Googulator>contains all the xz sources and checksums

<Googulator>I also tested extracting a handcrafted mes-0.25.tar.xz in builder-hex0 - it works :)

<Googulator>(on x86, obviously)

<oriansj>Googulator: (0x7FFFFFFF & BIT31) would just result in 0; you want (0x7FFFFFFF | BIT31)

<oriansj>sounds like a solid size reduction across the board.

<oriansj>well assuming we strip out M2-Planet tests and don't include the 26+MB .git repo; I don't think we can get stage0-posix+builder hex0 under 1.44MB

<oriansj>unless we limit the reduced images to only the built source code of a single architecture.

<oriansj>and there will be 15.8MB of build artifacts before the final 1.4MB of final binaries produced.

<oriansj>oh and I finally moved the web_ide out of stage0;

<Googulator>| is what I actually had, just mistyped it here

<oriansj>ok, and thank you for fixing amd64

<oriansj>it'll save a bit of trouble when more RISC-V 64bit changes show up

<Googulator>well, it's not yet actually fixed

<Googulator>this was just one bug

<oriansj>fair enough.

<Googulator>ouch...

<Googulator>prob[i] = (ttt - (ttt >> kNumMoveBits));

<Googulator>could this be it?

<Googulator>prob[] is an array of uint32s, ttt is also an uint32

<Googulator>if this is actually a 64-bit copy instead of a 32-bit one, that would cause some serious corruption

<stikonas>stage0 and bootstrap was just mentioned on #mrustc :)

<oriansj>I guess ekaitz talk was heard by them

<Googulator>oriansj: https://github.com/oriansj/mescc-tools-extra/pull/21 updated with amd64 fixes, amd64 now successfully decompresses the ~90MB Linux tarball

<Googulator> https://gist.github.com/Googulator/d2970b95f953376504ebfd509f6bef21 updated as well, with the definitive x86 & amd64 checksums

<Googulator>wrap.c still doesn't build even with everything updated to the newest

<Googulator>m2libc & everything

<Googulator>Adding

<Googulator>#include <sys/types.h>

<Googulator>#include <stddef.h>

<Googulator>to the beginning of wrap.c makes it build

<Guest26>hi, why I'm getting rm: cannot lstat `*/Makefile.in': No such file or directory

<Guest26>rm: cannot lstat `*/*/Makefile.in': No such file or directory

<Guest26>when building live-bootstrap?

<fossy>Guest26: on what package?

<fossy>sorry for all the questions - what is your build method (chroot/bwrap/qemu/bare metal)?, what commit are you building from?

<fossy>anything special about your setup

<Guest26>on autocong-1.6.3

<Guest26>im building with chroot method with rootfs.py script

<fossy>could you check your sha256sum of automake-1.6.3.tar.bz2 in the distfiles/ directory?

<fossy>also your ./rootfs.py command would probably be helpful too

<fossy>theres a possibility it was some strange transient issue and if you re-ran it wouldn't occur again

<fossy>OOH, are you in WSL?

<fossy> https://github.com/fosslinux/live-bootstrap/issues/379 -- this is a known issue if so

<fossy>unfortunately i don't have access to a WSL system, but i'm pretty sure Googulator has a fix in the works

<matrix_bridge><Andrius Štikonas> Guest26: are you Guest25 from yesterday? If so I replied to you that I am working on 64 bit bootstrap too...

<matrix_bridge><Andrius Štikonas> But nothing is completed yet

<fossy>also, unfortunate bare metal bootstrap news. neither of my two (veryish) old laptops succeed on bare metal (one is core2duo era, other i think is pentium m era)

<fossy>pentium m era gets up to make_fiwix_initrd and hangs, core2duo era crashes in the middle of srcfs right at the beginning

<fossy>need to investigate further, but is going to be a trek

<fossy>i suspect the pentium m era might not have enough ram

<fossy>(only has 2GB)

<fossy>and so make_fiwix_initrd is trying to write to non existant memory

<Guest26>Yes I am geust25 from yesterday

<Guest26>I am on linux from scratch based linux

<fossy>o.o

<fossy>my core2duo laptop crashes on reading automake-1.9.6.tar.bz2 for srcfs... around 32MiB in?

<fossy>not sure of any logical cause

<matrix_bridge><Andrius Štikonas> Oh, that's already in fiwix...

<fossy>i'm not sure what we call the step

<matrix_bridge><Andrius Štikonas> Oh no that's builder-hex0

<fossy>the one where it does "src" "filename" "src" "filename" ....

<fossy>yep

<matrix_bridge><Andrius Štikonas> Oh, and were you able to get anywhere with stage0-uefi?

<fossy>not yet, i have a few ideas floating around in my head, just need to give them a go

<matrix_bridge><Andrius Štikonas> I think it's almost at the POSIX level for x86_64...

<matrix_bridge><Andrius Štikonas> Probably just cp needs fixing

<fossy>hooray :)

<matrix_bridge><Andrius Štikonas> Well of course we still don't have a working tcc there...

<oriansj>Googulator: your pull was merged and I can confirm all of my unxz tests pass now for amd64; great job ^_^ and thank you so much.

<Googulator>fossy: 3GiB is the absolute minimum

<Googulator>A failure 32MiB into srcfs sounds like BIOS not properly implementing Int 13h extended reads

<Googulator>only using the first 16 bits of the LBA field

<Googulator>2^16 * 512 bytes = 32MiB

<oriansj>Googulator: I can confirm your wrap.c issue (I forgot to push to github >.<)

<oriansj>will update stage0-posix later today with the new checksums.

<matrix_bridge><Andrius Štikonas> oriansj: also please update changelog when you update stage0-posix

<oriansj>thank you for the reminder ^_^

<Googulator>oriansj: would it be possible to get a commit in the stage0-posix repository with submodules updated to the current (working) ones with xz?

<Googulator>I would need it to merge xz support into live-bootstrap, which pulls stage0-posix as a submodule.

<oriansj>Googulator: well yes, I am doing that right now

<oriansj>(more exactly I am verifying the checksums for all architectures and will then be doing a commit

<oriansj>)

<oriansj>pushed

<stikonas>just tested that acessing arrays using reverse notation doesn't work in M2-Planet

<stikonas>which I guess is expected...

<stikonas>got segfault from https://paste.debian.net/1306724/

<fossy>stikonas: i've never seen that syntax before, lol. is that the same as a[1]? why would one ever use that?

<stikonas>fossy: yeah, I haven't seen it before either

<stikonas>but apparently it works even in tcc

<stikonas>and yes, a[1] == 1[a]

<stikonas>I guess historically compilers considered it as *(a + 1)

<stikonas>which is the same as *(1 + a)

<stikonas>so it "accidentally" worked and ended up in standard

<fossy>ah, that would make sense

<stikonas>but it might catch somebody unaware

<stikonas>when you use 1[a] :D

IRC channel logs

2024-02-08.log