IRC channel logs

<aggi>i'll do some runtime testing of and with tcc-head next, compiling fiwix and a few other things; it should work since it's been tested with TinyCC/OS extensively before

<aggi> https://codeberg.org/aggi/tiny-bootstrap/src/branch/master/steps-tiny/tcc-head done.

<aggi>i see 0.9.26 received notable patching for ARCH=arm|riscv

<aggi>so far i've only swapped 0.9.27 for tcc-head

<aggi>for 0.9.26 i need to dissect a patchset from bootstrapple-branch to rebase this onto tcc-head (for x86_32 at least)

<aggi>since tcc-head does not yet pass with pnut

<aggi>seems it's mainly #if HAVE_LONG_LONG which could have caused trouble with pnut

<aggi>not sure if there is other trouble sources which block against mescc and/or pnut

<aggi>another problem with this, i cannot test any other than x86_32, even when a rebase onto tcc-head succeeded

<aggi>so such a rebasing for tcc-head expands to rather many test-case with mescc|pnut and ARCH=x86|arm|riscv|... which i can't cover

<aggi>which too raises the question: is it worth any effort (since i can't confirm feasibility yet)?

<aggi>thing is, tcc-head is receiving regular updates for ARCH=arm|riscv, and 0.9.26 dates back 10years almost - who knows how many backports were/are necessary if anytime live-bootstrap intends to fully support riscv|arm (don't know the status of this)

<janneke>mwette: trying to build nyacc-3.04.2, i get:

<janneke>nyacc/lang/c99/cpp.scm:241:19: include-from-path: file not found in path in subform "nyacc/lang/c99/mach.d/cpp-act.scm" of (include-from-path "nyacc/lang/c99/mach.d/cpp-act.scm")

<janneke>make[1]: *** [Makefile:102: nyacc/lang/c99/ffi-help.go] Error 1

<janneke>ACTION adds

<janneke>(add-after 'configure 'build-cpp-act.scm

<janneke> (lambda _

<janneke> (with-directory-excursion "module"

<janneke> (invoke "make" "nyacc/lang/c99/mach.d/cpp-act.scm")

<janneke> (invoke "make" "nyacc/lang/c99/mach.d/c99-tab.scm"))))))))))

<mwette>janneke: no pre-built files, so you need to look at module/nyacc/lang/c99/mach.gen to see how to build those; also, module/Makefile.in to see that these are generated during a build

<ekaitz>mwette: yesterday i talked with stikonas and it looks like mescc can build mes!

<ekaitz>still, there are a few issues with tinycc

<mwette>ekaitz: thanks, good news (for me)

<mwette>I hope they are not cpp issues !

<ekaitz>mwette: https://paste.debian.net/hidden/74ec4175

<ekaitz>not very informative

<ekaitz>but it feels like some output has changed

<mwette>all the (loop lst acc)'s are defined in boot-nn.scm files

<mwette>what's the last version that worked?

<ekaitz>i have no idea

<mwette>kk

<ekaitz>stikonas would know better

<ekaitz>ACTION is incapable of remembering version numbers

<matrix_bridge><gtker> stikonas: Pushed M2libc update on M2-Planet

<ekaitz>stikonas: in qemu 10.2.1 tcc-boot0 segfaults, do you experience the same issue?

<ekaitz>and calling the same command by hand is a pain in the fucking balls because tcc requires things to be declared with quotes because they paste the definitions like they were strings or some shit

<ekaitz>ffffffff

<ekaitz>ACTION is very mad

<aggi>why did live-bootstrap keep two different tcc-versions?

<aggi>what's the reason been 0.9.26-patchset was not rebased onto 0.9.27?

<aggi>and, had there been any other undesireable changes to later tcc-head?

<aggi>since 0.9.26 was patched for mescc and riscv|arm, did those latter ARCH pass live-bootstrap up until this tcc-version?

<aggi>with x86_32 the transition from 0.9.26->tcc-head seems not problematic, and since this is the only ARCH i'll bother with that's of no concern for me

<aggi>currently i tend to prefer: mescc|pnut -> tcc-head -> tcc-head (instead of 0.9.26 -> tcc-head)

<aggi>one obvious disadvantage would be, live-bootstrap may not easily pin a checksum for tcc

<aggi>but, if there is two options with mescc|pnut then bit-identical "reproducible-builds" could be confirmed with this instead of pinning a checksum

<aggi>x86_32 only; which is why the question is relevant if ARCH=x86|riscv could be sacrificed intermediately if their current state was not confirmed with live-bootstrap anyway yet

<aggi>and then be re-established with tcc-head, which is where active development is done for ARCH=riscv|arm

<aggi>except, if there was plans to drop tinycc from live-bootstrap (which there was rumors to fully replace that with mescc, please don't quote me on that)

<aggi>i guess live-bootstrap for ARCH=arm|riscv|.. was hacked up until M2 (and mescc available maybe), that's all preceeding stages before tinycc anyway

<aggi>beyond M2 those various ARCH are blocked for several other reasons too (fiwix, tinycc, gcc-4.x backports for aarch64/riscv64?)

<aggi>and since i focused on tinycc/os with linux-2.4 kernel for some weird reasons, there's a whole lot of other questions

<aggi>because, for riscv64|aarch64 bootstrapping may be _forced_ to transition to latest gcc/kernel-versions (which x86_32/tinycc/os is NOT, that's been the idea with it)

<aggi>had stage0-posix-riscv|arm been confirmed to arrive at tcc-0.9.26 by anyone?

<aggi>seems it is up until the stage of GNU mes/mescc where support for those ARCH are actively developed and tested, not any further.

<aggi>now that's interesting, because currently it is latest c++ compilers in essence which can drive riscv|aarch64 kernels/userspace

<aggi>but this gap is extremely difficult to bridge (or not feasible at all), regardless of tinycc/fiwix involved or none

<aggi>it's amazing nonetheless, live-bootstrap can spawn some LISP/scheme machine for riscv|arm

<aggi>ok, and ARCH=arm|riscv seem blocked from another side: builder0, that's x86_32 exclusive too

<stikonas>ekaitz: not sure what was the last working nyacc version...

<stikonas>maybe janneke knows better...

<mwette>not that important since many change lately; can you run mescc stuff from gdb?

<ekaitz>mwette: wdym by mescc stuff? the result? or mes while it's running mescc

<stikonas>yeah, I'm confused too, gdb woudn't work on mescc, only on ems

<stikonas>it's probably hard to tell what is happening in mescc from gdb

<ekaitz>stikonas: not really

<ekaitz>there are a few tricks one can do

<ekaitz>when it explodes, it triggers a segfault

<ekaitz>from there you can try read all values of R1

<ekaitz>from the mes stack

<ekaitz>it's very tricky though

<mwette>thanks

<mwette>nyacc has a debug flag that prints state/token as it is parsing

<ekaitz>oh that's very good

<mwette>IIRC you can also print include file paths as they are opened

<mwette>yes: (parse-c99 #:debug #t #:show-incs #t)

<mwette>to see the meaning of the state number, use code in lang/c99/mach.gen to print the ,gram.txt file

<aggi>i see, tcc-head is a pain with rebasing HAVE_LONG_LONG, with a few more long long and int64 inside tccgen.c for example

<aggi>i'm halfway through the 0.9.26 patchset from janneke to rebase this onto head, x86_32 only, skipping all riscv/arm stuff

<aggi>regardless of specific tcc-version, the first transition from pnut|mescc towards tcc seems a little flaky

<aggi>mentally i'm stuck in a loop with this

<aggi>it's several tasks, first seeing to mess|pnut compiled tcc-head behaves, then next a little more scripting for simple nightly-builds of this

<aggi>next, confirming once or twice pnut->tcc and mescc->tcc remain bit-identical on tcc-head

<aggi>then live-bootstrap could roll-along with one version on tcc-head always; which triggers the mental loop again, what's the benefit if there is no other than ARCH=x86_32 on the horizon with any approach at that stage?

<aggi>stikonas: is/was this the plan to drop tinycc from live-bootstrap?

<stikonas>well, once mescc can build tcc mob, then we can drop tinycc

<mwette>ekaitz: I'm finding stuff, maybe, just parsing tcc code from nyacc directly. choke on asm-tok.h maybe

<stikonas>or once other compilers support more arches

<mwette>not tcc, but tinycc

<ekaitz>oh

<ekaitz>that might be the issue

<aggi>stikonas: ok, from the perspective of live-bootstrap this is a plausible scenario, to drop tinycc

<stikonas>anything is plausible

<stikonas>perhaps one day M2-Planet can build tcc, or perhaps one day mescc can build gcc

<aggi>however, from another perspective, currently tinycc is the ONLY known complete C-toolchain (other than GNU/g++ llvm/c++) which a _complete_ GNUish/POSIX can be driven with (TinyCC/OS)

<stikonas>well, even non C bootstrap is possible

<aggi>and having a look at it this way, it's a little annoying tcc-0.9.26 BLOCKED against live-bootstrap

<stikonas>e.g. somebody might bootstrap assembly to say rust without ever touching M2-Planet, mes/mescc, tcc and gcc

<stikonas>thoguh that is probably quite a bit of work

<ekaitz>mwette: asm-tok.h is from the bootstrappable tinycc?

<ekaitz>i don't see that file in mob

<ekaitz>or is it generated?

<mwette>sorry i386-tok.h my bad

<ekaitz>oh ok

<ekaitz>mwette: there's a lot of funny macroing in there

<mwette>not surprised

<aggi>stikonas: would live-bootstrap (main branch) be willing to roll along with tcc-head?

<stikonas>at some point we might upgrade to a snapshot

<stikonas>that has better riscv support

<stikonas>but given that mescc might be soon able to build it directly

<stikonas>I don't think we are in a rush to do it now

<ekaitz>not only directly but also faster!

<aggi>i'm thinking of regular nightly-builds even, tracking tcc-head

<stikonas>nyacc 3 pregen file regeneration was much slower though

<stikonas>compared to when I tried nyacc 1.0.0.2

<stikonas>1.00.2

<stikonas>ekaitz: but perhaps your speedups will bring it down again

<stikonas>well, tracking tcc-head is not good for reproducible builds

<aggi>ok, i would consider this settled if pnut|mescc|stack_c confirmed bit-identical output up until steps/tcc-head

<aggi>with a git-tag across all involved repositories once in a while

<mwette>no clue why pregen file regen would be slower;

<mwette>I did find one cpp bug in 3.04.2

<ekaitz>yay!

<mwette>there are more

<mwette>and they use attributes ; do you #define those out?

<ekaitz>let me show you the call... it's long

<ekaitz>./tcc-boot0 -g -v -static -o tcc-boot1 -D BOOTSTRAP=1 -D HAVE_BITFIELD=1 -D HAVE_LONG_LONG=1 -D HAVE_SETJMP=1 -D HAVE_SETJMP=1 -I . -I /gnu/store/i4h4x7qbycww5hadif3c11slzrylrp8s-mes-boot-0.27.1//lib -I /gnu/store/i4h4x7qbycww5hadif3c11slzrylrp8s-mes-boot-0.27.1//include -D TCC_TARGET_RISCV64=1 -D inline= -D

<ekaitz>CONFIG_TCCDIR="\"/gnu/store/2g8bkmr4y66vxxy4sdjg84vygpk8lp33-tcc-boot0-0.9.26-1157-gdd46e018/lib/tcc\"" -D CONFIG_TCC_CRTPREFIX="\"/gnu/store/2g8bkmr4y66vxxy4sdjg84vygpk8lp33-tcc-boot0-0.9.26-1157-gdd46e018/lib:{B}/lib:.\"" -D CONFIG_TCC_ELFINTERP="\"/lib/mes-loader\"" -D CONFIG_TCC_LIBPATHS="\"/gnu/store/2g8bkmr4y66vxxy4sdjg84vygpk8lp33-tcc-boot0-0.9.26-1157-gdd46e018/lib:{B}/lib:.\"" -D

<ekaitz>CONFIG_TCC_SYSINCLUDEPATHS="\"/gnu/store/i4h4x7qbycww5hadif3c11slzrylrp8s-mes-boot-0.27.1//include:/gnu/store/2g8bkmr4y66vxxy4sdjg84vygpk8lp33-tcc-boot0-0.9.26-1157-gdd46e018/include:{B}/include\"" -D TCC_LIBGCC="\"/gnu/store/2g8bkmr4y66vxxy4sdjg84vygpk8lp33-tcc-boot0-0.9.26-1157-gdd46e018/lib/libc.a\"" -D CONFIG_TCCBOOT=1 -D CONFIG_TCC_STATIC=1 -D CONFIG_USE_LIBGCC=1 -D TCC_MES_LIBC=1 -D

<ekaitz>TCC_LIBTCC1="\"libtcc1.a\"" -D ONE_SOURCE=1 -L . tcc.c

<ekaitz>something like that

<ekaitz>holy shit

<ekaitz>mwette: we only remove inline from what I see there

<mwette>yikes. OK. I need to see if I support that placement.

IRC channel logs

2026-03-12.log