IRC channel logs

<oriansj>mihi: it has to do with an earlier version of blood-elf which incorrectly identified a label inside of a string literal.

<oriansj>with resulted in a linking failure as the " :foo" might not have an actual :foo label for hex2 to link to

<oriansj>^with^which^

<stikonas>so I guess we no longer need it

<mihi>oriansj, thanks. That makes sense. I tend to always forget that blood-elf exists...

<oriansj>stikonas: well weird strings are still needed for cases such as "\"foo\""

<stikonas[m]>I see

<stikonas[m]>And I've converted hex2_amd64 to new defines

<oriansj>nice

<oriansj>also I don't have sufficient confidence that issue is completely eliminated from blood-elf yet for all arbitrary inputs and leaving it doesn't really cause problems either.

<stikonas>well, let's leave it...

<stikonas>there are more important issues...

<stikonas>hmm, so hex0_x86.S works correctly regarding return code but not the hex0.hex0 version

<stikonas>doras: I guess I just need to sync whatever is in .S file to .hex0

<stikonas>hmm, "add register, label" seems to mean different thing in NASM and GAS (intel syntax)

<stikonas>not sure how to translate nasm syntax to something gas understands

<doras>I wish I could help :)

<doras>By the way, here's the MR that bootstraps freedesktop-sdk from our new binary seed which itself bootstraps from live-bootstrap's sysc: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/11557

<doras> * By the way, here's the MR that modifies freedesktop-sdk to bootstraps from our new binary seed which itself bootstraps from live-bootstrap's sysc: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/11557

<stikonas>maybe I should try to advertise it a bit more tomorrow...

<stikonas>given that this affects flatpaks

<stikonas>so might be appropriate for places like planetkde.org

<stikonas>ok, you still have rust there...

<doras>Yes, Rust is not a solved matter unfortunately.

<doras>Maybe in a few more years when rust-gcc is more capable.

<stikonas>well, there is mrustc...

<stikonas>but that is more complicated

<stikonas>and I'm also struggling with it a bit on Gentoo in my overlay

<stikonas>though some of that might be my misundertanding of Portage

<stikonas>I could build rustc 1.54 outside portage

<stikonas>but something fails with error when I was running same commands in portage

<doras>stikonas: we want to be able to build Rust for all the architectures we can support at the moment (so x86-64, aarch64, riscv64, powerpc64le, i686, armv7). Can a bootstrap path starting with mrustc result in a native Rust toolchain for each of these architectures?

<stikonas>you can cross-compile rust

<stikonas>so yes, but it's not too simple

<stikonas>at least it wasn't when I did it

<stikonas>at some point cross-compiling needed building rust with nightly features enabled

<stikonas>s/nightly/unstable/

<stikonas>mrustc itself mostly tragets 64-bit arches

<stikonas>it's very hard to build it on 32-bit systems

<stikonas>(due to 3G memory limit)

<stikonas>doras: and I can see the bug in kaem-optional

<stikonas>it might be something introduced by me earlier...

<stikonas>when trying to reduce its size :(

<doras>:(

<doras>Findings the bug is still good news, though :)

<stikonas>yeah, the binary size will increase a bit :(

<stikonas>but we shouldn't reduce it at the cost of bugs

<stikonas>anyway, I'll fix it but still will take some time, maybe tomorrow

<stikonas>it needs serious changes to .hex0...

<stikonas>sicne jumps and offsets are now different

<stikonas>and I might also change to GAS syntax at the same time...

<doras>Thanks for looking into it

<nektro> https://bpa.st/raw/IGNMO does this error look familar, adapted from amd46/kaem.run + mescc-tools-extra.kaem

<fossy>no.. i've never seen that before

<fossy>what have you changed?

<nektro>im not sure

<nektro>the contents of the referenced M2-Planet-000000 file is https://clbin.com/hG829

<nektro>m2-mesoplanet file is https://clbin.com/Ib7FT

<sam_>stikonas[m]: yes, cross-compiling rust is often a pain

<sam_>stikonas[m]: also, please keep in mind you can ask me if you need to

<sam_>i may not always have the answers, ofc

<sam_>but happy to try

<fossy>gosh, gcc's abuse of autotools is an absolute mess

<fossy>autoreconf doesn't even pick up the existance of subdirectories

<fossy>and half of the scripts are broken with the supposed versions that are meant to be used

<fossy>so much for simplicity :\

<oriansj>nektro: that error looks extremely familiar

<oriansj>it simply means the file amd64_defs.M1 is lacking a DEFINE for mov_rax, (which if I remember correctly should be: DEFINE mov_rax, 48C7C0 )

<oriansj>so you might be on the wrong M2libc commit

<nektro>nice catch! i was on the latest commit of mescc-tools-extra but the M2libc submodule hasnt been pushed forward in 10 months according to github

<nektro>checking my local amd64_defs.M1 that define is indeed missing

<sam_>fossy: yeah it's very frustrating

<sam_>none of it is idiomatic autoconf at all

<sam_>fossy: plus if you send any patches for it, nobody is really interested

<sam_>all the build system maintainers listed are long-gone too

<sam_>maybe bar one but we didn't get a reply from them

<fossy>can anyone think of any strange cases where there might be autotools generated files left around after doing:

<fossy>1. autoreconf on all dirs with configure

<fossy>2. automake on all dirs with soley Makefile.in

<fossy>sam_: this is the only substantative patch since they changed autoconf versions -_- https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=25861cf3a88a07c8dca3fb32d098c0ad756bbe38

<fossy>(and i needed it, haha)

<stikonas[m]>fossy: you might also need to run aclocal?

<stikonas[m]>although maybe aclocal is correctly launched by autoreconf

<stikonas[m]>so perhaps 1. and 2. is fine (plus rebuilding top-level gcc stuff with autogen)

<stikonas[m]>fossy: another question is what backends are we building? So far only C and C++ are enabled

<stikonas[m]>just keep it at that? Or do we need more?

<doras>For what's it worth, freedesktop-sdk only needs C/C++.

<doras>what it's*

<stikonas>hmm, perhaps it's not possible to do what I want with intel syntax...

<stikonas>so I was able to get required opcode with this in AT&T syntax: mov $default_file, %ebx

<stikonas>but if I use "mov ebx, default_file" in Intel syntax, it's the same as "mov default_file, %ebx" in AT&T and uses "8b 1c 25" instead of "bb" opcode

<oriansj>mov [default_file], ebx

<stikonas>"mov ebx, [default_file]" also generates wrong opcode

<stikonas>lea ebx, [default_file] generates even different opcode but it does have the right behaviour

<stikonas>I tried disassembling it with objdump -M intel but it was not too helpful

<stikonas>as it does not show label names, it just shows numbers

<stikonas>good one was mov ebx,0x804a000 and bad one was mov ebx,DWORD PTR ds:0x804a000

<oriansj>ds is using the data segment register; most code should be in the cs (code segment)

<mihi>stikonas, I think you want "mov ebx, OFFSET default_file" (at least that was the syntax used with MASM)

<stikonas[m]>Let me try that

<oriansj>well there are only 3 encodings possible bb 00a00408, 8b 1d 00a00408 and 89 1d 00a00408

<stikonas>mihi: thanks! it does work

<mihi>you are welcome

<stikonas>hmm, perhaps this will not affect .M1 file anyway

<stikonas>in .S file I now have "mov ebx, OFFSET default_file" but for M1 syntax I think it will still be mov_ebx, &default_file

<stikonas>maybe I should have use AT&T syntax for new defines, it's a bit more verbose and maps better to M1...

<stikonas>doras: I have pushed fixed x86/kaem-minimal.hex0

<stikonas>we still need to copy it to bootstrap seeds, and update stage-posix and live-bootstrap submodules before it works for you

<stikonas>but those are easy

<stikonas>also x86/kaem-minimal is now using new defines

<stikonas>rickmasters: by the way, did you have any issues with curl checksum?

<rickmasters>Sorry, not sure what you mean.

<stikonas>on some older linux somehow curl in live-bootstrap was automatically disabling IPv6 support

<stikonas>it's now fixed in live-bootstrap https://github.com/fosslinux/live-bootstrap/commit/5f805e65f32ab6d10f47bdc4aa38f706cc7b87dc

<stikonas>but I wonder what was happening in fiwix

<Mikaku>stikonas: Fiwix don't has network support (yet)

<rickmasters>Fiwix doesn't run curl, that's after linux boots.

<stikonas>yes, we don't run it, just build it

<stikonas>it was the building step that was not reproducible in live-bootstrap

<stikonas>with older linux kernels it was disabling IPv6. Anyway, fixed by specifying --enable-ipv6

<rickmasters>stikonas: no, I didn't see that problem

<rickmasters>stikonas: if there was some (unnoticed) problem building it I suppose it could always be built after linux boots.

<rickmasters>stikonas: by the way, I disabled checksum checking in my development due to musl differences I've mentioned before.

<stikonas>oh I see, then you indeed wouldn't have noticed it

<rickmasters>stikonas: Eventually I'm going to regenerate the checksums with my mods and test versus linux. I think there may be work remaining...

<stikonas>oriansj: https://github.com/oriansj/bootstrap-seeds/pull/35

<stikonas>fixed exit code of kaem-optional that doras requested and also switched to new defines

<doras>stikonas @stikonas:libera.chat: great! Thanks!

IRC channel logs

2023-01-22.log