IRC channel logs

<fossy>urgh, not openssl problems again

<fossy>i'm working on getting bearssl in a state suitable for bootstrapping

<fossy>should be ready soonish

<matrix_bridge><Andrius Štikonas> Well, after Linux openssl would do

<matrix_bridge><Andrius Štikonas> But before that, it would be nice to have something small

<fossy>well yeah

<fossy>openssl is also just much more complicated lol

<matrix_bridge><Andrius Štikonas> I wonder if bearssl is buildable with tcc...

<matrix_bridge><Andrius Štikonas> Though we have no network before Linux anyway

<stikonas>oriansj: have you seen this PR https://github.com/oriansj/M2-Planet/pull/57 I was just made aware of it today

<lanodan>bearssl at least with upstream tcc builds fine, including tests

<stikonas>yes, we have upstream tcc too

<stikonas>(in live-bootstrap)

<notgull>I'm trying to get the AMD64 part of the stage0-posix project on my system, but I keep running into errors. When I try to investigate the executable, I get the file type: "/tmp/M0: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), can't read elf program headers at 1073741824, no section header"

<notgull>I used hex2 to compile it from the `AMD64` submodule, any ideas?

<stikonas>notgull: hi

<stikonas>did you run hex2 manually?

<stikonas>my guess would be wrong optoins then...

<notgull>I mean, here's the commands I ran:

<notgull>cat ../AMD64/ELF-amd64.hex2 ../AMD64/M0_AMD64.hex2 > /tmp/M0.hex2

<notgull>./bin/hex2 -f /tmp/M0.hex2 -o /tmp/M0

<notgull>Is there supposed to be another options on hex2?

<stikonas>yeah, we need to specify --little-endian --architecture amd64

<stikonas>and I think --base-address

<stikonas>kaem scripts know about these options

<stikonas>(or if you run make test-amd64 from stage0-posix directory)

<notgull>It looks like specifying the first two options made it compile

<stikonas>(which just kicks of ./bootstrap-seeds/POSIX/AMD64/kaem-optional-seed

<notgull>Oh, let me run that manually

<stikonas>well, it will probably crash

<stikonas>without base-address

<stikonas>as then base-address is assumed to be 0

<notgull>stikonas: You would be correct

<stikonas>most other reasonable numbers would work

<stikonas>I guess as long as it's outside reserved ranges, something over 1MiB would probably work

<notgull>Ok now I have the executable I wanted, thanks!

<stikonas>stage-posix-amd64 uses 0x00600000

<stikonas>for base address

<stikonas>but it is kind of arbitrary choice

<notgull>Mmm, I imagine it's largely irrelevant?

<stikonas>yeah, largely irrelevant

<stikonas>nothing should change as long as Linux accepts that base address in elf header

<stikonas>in fact almost all stage-posix-amd64 binaries are position independent

<notgull>nice nic3

<stikonas>(I think kaem-optional-seed is the only exception for now_

<notgull>Anyhow what I'm trying to do is get cc_amd64 working

<stikonas>but even for PIE binaries, Linux elf loader doesn't like if base address is 0

<notgull>I wanted to see what its limits are

<stikonas>oh, cc_amd64 is fairly limited

<notgull>So I know what I can and can't add to M2-Planet

<stikonas>yeah, basically looking at M2-Planet would give you a good idea what is supported

<stikonas>for structs, I think you are limited to struct pointers

<notgull>Mmmm, I take it for loops are not?

<stikonas>loops are fine

<stikonas>for while and do while should work

<notgull>I see

<stikonas>well, for loops can't do for (int i = 0; ...)

<notgull>My assumption is that "unsigned char" and any other "unsigned [X]" types aren't supported either, right?

<stikonas>you need to declare int i = 0 before for loop

<notgull>(In M2-Planet as well)

<stikonas>I think they are

<stikonas>probably better support in M2-Planet than in cc_x86

<stikonas>if you see, M2-Planet assembly outputs, i.e. emit_out functions

<notgull>I'm trying to compile QBE with M2-Planet, and the error I'm getting is this

<stikonas>then you can see lots of signed vs unsiged cases

<notgull>"/home/jtnunley/Projects/c9x/qbe/all.h:11:ERROR in typedef statement"

<stikonas>e.g. https://github.com/oriansj/M2-Planet/blob/master/cc_core.c#L1319

<notgull>That statement is: typedef unsigned char uchar;

<stikonas>arithmetic_recursion(additive_expr_a, "ADD R0 R1 R0\n", "ADDU R0 R1 R0\n", "+", additive_expr_stub_b);

<stikonas>oh, typedef might not be smart enough here

<notgull>Ah, I see

<stikonas>or maybe type name, let me check

<stikonas>types are here https://github.com/oriansj/M2-Planet/blob/master/cc_types.c

<stikonas>(for M2-Planet at least, cc_x86 supports less)

<notgull>I looked there, I see "unsigned" but not "unsigned char"

<stikonas>anyway, I wouldn't use cc_x86 for anything other than M2-Planet

<notgull>So I wanted to take a crack at rewriting that file a bit, but I needed to know what cc_x86 supporte

<notgull>supported*

<stikonas>oh, maybe the problem is that only 1 word types are supported

<stikonas>anyway, looks like indeed there is no "unsingned char"

<stikonas>only unsinged for "unsigned int"

<notgull>Yeah that's what I figured

<stikonas>it is a fairly simple compiler...

<notgull>I saw, yeah

<notgull>I was investigating if it's feasible to add that in the current compiler

<notgull>Make it so `type_name()` can handle it

<stikonas>well, you can always at least look ahead for the further tokens

<stikonas>global_token->next and global_token->next->next, etc...

<notgull>That's what I figured would work

<stikonas>so perhaps some kind of longest match

<stikonas>and as for cc_x86, it basically has no support for pre-processor

<notgull>Yeah, cc_x86 is like

<stikonas>no more advanced stuff like switch

<notgull>Basically just enough of C

<stikonas>indeed

<stikonas>perhaps a bit more than minimal

<stikonas>we could probably do without unions in cc_x86 even though we have them

<notgull>My overarching goal here is making it so dozer can be compiled early on in the bootstrap chain

<notgull>Right now it can be compiled by TinyCC, sort of

<notgull>But I'd like to introduce it as early as I can

<stikonas>well, the earliest possible stage is M2-Planet I think

<notgull>That's what I thought

<stikonas>cc_x86 is too limited

<notgull>I originally wanted to do mescc but I don't know enough Scheme to effectively modify it to compile QBE

<stikonas>and anything earlier would required rust_x86 written in assembly :D

<stikonas>which is not an option I think

<notgull>I would rather dips my toes in acid

<stikonas>yeah, scheme tends to be hard for most people

<stikonas>I had to modify mescc a few times

<notgull>You can probably get some kind of "proto-Rust" written in Assembly, that supports structs and impls and stuff but not traits and generics

<stikonas>and it's always hard for me

<stikonas>though some people like scheme a lot and find it easier

<notgull>But at that point you basically have C written with a different syntax, and at that point you may as well just use C

<stikonas>exactly

<notgull>Frankly it's less of Scheme itself and more of mes's codebase

<notgull>It's quite dense for a Scheme program

<notgull>Actually, hmm

<notgull>I wonder if it would be possible to make it so M2-Planet could compile TinyCC?

<stikonas>I don't see why not

<notgull>Let me see what happens if I run M2-Planet on one of tcc's headers

<stikonas>though probably quite a bit of work requried

<stikonas>perhaps not in terms of missing features

<notgull>Right

<stikonas>but there is a lot of fiddling at the end when you are really close to bootstrapping tcc

<stikonas>and need to sort out various bugs

<stikonas>i.e. tcc depends on int being 4 bytes, etc...

<notgull>Ah, it bails on a multi-line macro

<stikonas>hmm, probably limitation of pre-processor

<notgull>I figured

<stikonas>there is M2-Mesoplanet preprocessor

<notgull>Let me try mesoplanet instead

<stikonas>that we have

<stikonas>it is a bit more powerfull

<notgull>'unable to read file: "config.h"'

<notgull>Is there a way to set include path in mesoplanet?

<stikonas>I think so

<stikonas>might be just -I but let me check

<stikonas>oriansj: do you remember?

<stikonas>looks like -I should work

<notgull>`./M2-Mesoplanet -f ~/Projects/TinyCC/tinycc/tcc.h -I ~/Projects/TinyCC/tinycc` fails with the same error

<stikonas> https://github.com/oriansj/M2-Mesoplanet/blob/main/cc.c#L92

<notgull>I see that line, it sets "M2LIBC_PATH"

<stikonas>that's path to M2libc directory...

<stikonas>maybe it doesn't accept any other include dirs

<stikonas>just allows searcdhing for M2libc

<stikonas>hmm

<notgull>I ran with the PWD set to tinycc's dir, and it looks like it fails when it tries to read in stdarg.h

<notgull>So it looks like stdarg.h would need to be added to M2libc

<notgull>...which means vararg support would need to be added to M2-Planet

<notgull>*le sigh*

<stikonas>hmm, do we have them in mescc

<stikonas>anyway, even mescc only builds patched tcc

<stikonas>though I think it does have varargs...

<stikonas>ekaitz and I had some issues with varargs when bootstrapping tcc from mescc on riscv64...

<notgull>I'm assuming this would be an issue in building QBE as well, since QBE has vararg functions

<stikonas>yeah, so that's one of the missing features...

<ekaitz>stikonas: didn't we fix those?

<stikonas>ekaitz: in mescc

<stikonas>this is M2-Planet

<ekaitz>oh

<stikonas>M2-Planet doesn't seem to have any varargs

<stikonas>probably another missing feature would be support for "i++ or ++i"

<stikonas>M2-Planet doesn't support pre or post inc/de-crement operators

<notgull>Right, I think QBE uses those too

<stikonas>type sizes might be an issue too as I've mentioned

<notgull>Mmm

<stikonas>so it's still quite a bit of work...

<stikonas>even though M2-Planet is not that far behind mescc

<notgull>Yeah I think my plan is probably just going to be to use TinyCC as my bootstrap base for now

<stikonas>well, that's a good start anyway

<notgull>Then once dozer is in a more manageable state and I can bootstrap rustc v1 from there, I'll go back and see if I can make any progress from the other end

<stikonas>tcc is still relatively early

<notgull>Mmm yeah, and even then it takes a bit of work to get it working with QBE

<stikonas>yeah, QBE was mentioned in this channel before

<notgull>like https://codeberg.org/notgull/dozer/src/branch/main/tools/tinycc_qbe_conv.c

<stikonas>but nobody tried it from M2-Planet...

<stikonas>oh you mean using tcc with qbe

<notgull>Yeah tinycc can compile qbe relatively easily, but it can't handle QBE's assembly syntax

<stikonas>yeah, tcc assembly support is not too good

<notgull>I think one of the Hare guys actually proposed a patch to tcc to fix that

<stikonas>which I think is because tcc is not a C to assembly compiler...

<notgull>Yeah here https://lists.nongnu.org/archive/html/tinycc-devel/2024-09/msg00005.html

<stikonas>it is directly converting C to binary code

<stikonas>well, they should just push that patch to tcc

<stikonas>if there were no objections

<notgull>Can you just, do that?

<stikonas>tcc mob branch is open to pushes

<stikonas>yes, anybody can push

<notgull>Huh, let me try pushing it

<stikonas>there are instructions here https://repo.or.cz/tinycc.git

<stikonas>(just basic add remote, fetch, push...)

<notgull>Yeah it's been a month or so, I'll just push it...

<stikonas>though don't hold your breath about it ending up in release

<stikonas>there are calls for a new release there

<stikonas>but it has been now maybe 8 years...

<stikonas>ok, just 6...

<notgull>Mmm

<stikonas>but still

<notgull>Who's even in charge of that these days?

<stikonas>grischka I think is the maintainer

<Googulator>notgull: I'd suggest not using molassescc, I mean, mescc, for anything more than necessary

<Googulator>compiling tcc with mescc is the single slowest step of the early bootstrap, before we have a real Linux kernel - by comparison, the next set of recompiling tcc with itself is virtually instantaneous

<Googulator>compiling Dozer with mescc would probably take weeks even on a Zen 5 CPU

<notgull>I've pushed the TinyCC patch now

<notgull>Googulator: Yeah makes sense

IRC channel logs

2024-10-27.log