IRC channel logs

<stikonas>mid-kid: by the way, yoru gentoo instructions need specific rsync version

<stikonas>depending on the version (probably added patches) it tries to run autotools and fails...

<stikonas>anyway, that's something that we can improve later

<stikonas>mid-kid: also I think EXTRA_ECONF='--with-sysroot=/usr/$CTARGET --enable-shared' on line 147 should be EXTRA_ECONF="--with-sysroot=/usr/$CTARGET --enable-shared"

<webczat>ekaitz: hi. seems like it might be one of these macros :) probably from filename.h. these are parameterized macros.

<webczat>i removed their call and compilation passed

<ekaitz>webczat: YAY!

<webczat>curious if it's their expansion or something trivial like a space between macro name and parameters

<webczat>i mean they use space before a "("

<webczat>going to install newest mes just in case

<webczat>as i am one version too early. newest also could not compile make, but i can't guarantee it errored on same file

<webczat>0.25 vs 0.26

<ekaitz>0.25 and 0.26 are not very different i think

<ekaitz>mostly the differences are the module system in the scheme interpreter i think

<webczat>ekaitz: updating is still a good idea. that gives proof it was not fixed unless in the git master which I wouldn't know.

<webczat>and no it was not fixed. also just removing spaces before parens doesn't work. would be a silly thing but I somewhat hoped it's that simple

<matrix_bridge><Andrius Štikonas> webczat: 0.26 is very slow due to bugs, we are waiting for 0.26.1

<matrix_bridge><Andrius Štikonas> 0.26 runs mescc twice

<webczat>ekaitz: i have isolated the relevant code. or more like, i really don't know what's wrong, but I can now give you a file without any headers and with all needed macros that seems to cause the same effect.

<webczat>matrix_bridge: it is slow indeed, but i didn't notice 0.25 being much faster...

<webczat>ekaitz: https://paste.mod.gg/rbeknpazfaoo/0

<webczat>not sure if this is one of the macros or the whole expression.

<webczat>but here it is

<webczat>this alone causes "ast->type: not supported" to appear

<webczat>i made sure not to reclassify the expression by removing the variables, it's copied verbatim.

<ekaitz>stikonas: I fixed that double run in 0.26.1 i think

<ekaitz>the part of the "i think" is the version. I'm 100% sure i fixed it haha

<matrix_bridge><Andrius Štikonas> ekaitz: yes, but we don't have release yet

<ekaitz>not yet?

<ekaitz>oh true we don't have it yet

<ekaitz>ACTION is sad

<webczat>any idea about the file I sent?

<Googulator>webczat: the following one-liner seems to be sufficient:

<Googulator>int main() {0 < (0, 0);}

<webczat>i didn't quite know what's that supposed to do so i didn't do further shortening. and also I tried to use this macro and was able to compile an instance where it was used, so... unsure

<Googulator>also int main() {0 + (0, 0);}

<webczat>but just 0,0 or (0,0) isn't sufficient?

<Googulator>no

<Googulator>int main() {0 == (0, 0);} works even

<webczat>okay. that's why just using macro worked.

<Googulator>It's the combination of a numeric operator and the comma operator that triggers it

<webczat>mhmmm

<Googulator>basically it seems that (0, 0) is not an integer in mescc for some reason

<webczat>so it seems. i didn't even remember that , is an operator in c. i am a c# guy for a long time

<Googulator>I'm not sure if it's strictly considered an operator

<webczat>i think it is... i remember something.

<Googulator>but the core issue seems to be that comma-expressions don't correctly propagate types

<webczat>and i forgot what this returns.

<Googulator>It returns the value after the comma

<Googulator>& it's also a sequence point, meaning that the first argument is evaluated strictly before the second one

<ekaitz>do you manage to make a reproducer?

<webczat>Googulator: yeah. and it seems like an issue with no easy workaround. :) except... why was this comma even used here? why it couldn't just be the 0 without anything else?

<ekaitz>we can make a mescc test for it

<webczat>ekaitz: see above

<Googulator>ekaitz: yes, this one-liner:

<Googulator>int main() {0 + (0, 0);}

<ekaitz>oh

<ekaitz>that's cool

<webczat>i had a more complex one with macros but this one seems to be way better.

<Googulator>you can use any operator that expects a number in place of the +

<ekaitz>does int main(){ (0,0);} work?

<Googulator>yes

<ekaitz>aaah it needs a number

<Googulator>even int main() {0 == (0, 0);} does

<ekaitz>it needs to *expect a number

<ekaitz>good

<webczat>i wouldn't have enough patience in the bootstrap env to go that deep :) i'm connected to it over serial over lan/ipmi and am forced to use busybox vi. for me it's actually kinda... uncomfortable

<Googulator>(0, 0) is a valid expression, but it's not treated as a number

<Googulator>I just did "apt install mes"

<ekaitz>this is pretty testable, we can add that to mescc as a test and just leave it there

<webczat>Googulator: yeah i could... unsure if fedora has mes

<Googulator>debian has, but only 0.23 - luckily it does reproduce the same

<Googulator>ekaitz: backtrace with guile backend: https://paste.debian.net/1308786/

<ekaitz>yeah that makes sense to some degree

<ekaitz>i'll add the test and try run it in mes

<webczat>no mes in fedora :) would have to compile it. but don't seem to have to at this point

<ekaitz>install guix in fedora and use the one from guix

<ekaitz>:)

<ekaitz>we should report this to janneke anyway

<ekaitz>maybe it's a nyacc issue and there's nothing we can do about that

<webczat>ekaitz: it's probably easier to compile it locally :)

<ekaitz>installing guix is a piece of cake

<ekaitz>ACTION is really excited about guix

<webczat>also can anyone tell me what's the purpose of the original macro? why was the comma operator used there? wondering if I can patch that out or not without changing meaning.

<webczat>as in just 0 or (0)

<ekaitz>( printf(whatever), 190) does the side effect of printf but returning 190

<ekaitz>it's just an expression that calls things in order and resolves to the last one

<webczat>okay. but here ... it doesn't seem to have any side effects whatsoever

<Googulator># define FILE_SYSTEM_PREFIX_LEN(Filename) ((void) (Filename), 0)

<Googulator>this is the macro

<Googulator>it makes no sense whatsoever

<ekaitz>it's using Filename

<webczat>Googulator: unless this is a signal like hey, this variable is being used even though you don't see it? to some static code analyzers?

<ekaitz>maybe because they want the compiler not to complain

<ekaitz>you can just replace that with a 0

<webczat>i'm likely close then

<ekaitz>(i think)

<webczat>will do

<Googulator>I was thinking that maybe it's meant to "simplify" some_function((void) (Filename), 0) into some_function FILE_SYSTEM_PREFIX_LEN(Filename)

<Googulator>which is valid C, but really bad practive

<Googulator>*practice

<Googulator>but casting Filename to void makes even that meaningless

<Googulator>when used as a value, it's just a really contrived way of saying 0

<webczat>hmmmmmm

<webczat>now this is weird

<Googulator>maybe it was done to appease a compiler that considers the following an error:

<Googulator>#define FILE_SYSTEM_PREFIX_LEN(Filename) 0

<Googulator>because it thinks all arguments to a macro must appear in its definition

<Googulator>in that case, you can just do #define FILE_SYSTEM_PREFIX_LEN(Filename) /* Filename */ 0

<webczat>compiling this manually with mescc -c -I../src concat-filename.c works but reports undeclared stpcpy. which is actually weird as I'd expect it to appear including in a case when the mes libc doesn't declare it, it should be conditionally defined probably?

<webczat>however using build.sh script outright gives a segv without any error

<webczat>even after the change

<webczat>okay

<webczat>i define a macro HAVE_CONFIG_H with -D

<webczat>then I get a segv during parsing. no error

<webczat>it probably somehow conditionalizes itself on HAVE_CONFIG_H

<webczat>so it's a noop without it.

<webczat>or

<webczat>it doesn't understand -D?

<Googulator>-D is valid according to mescc --help

<Googulator>try with -DHAVE_KONFIG_H to see if it's specifically that

<Googulator>or just any -D

<Googulator>that causes it

<webczat>Googulator: try -DMACRONAME without giving it a value. :)

<webczat>but you need to give it a valid file

<Googulator>compiles fine

<Googulator>then it has to be something in the code that checks HAVE_CONFIG_H

<webczat>Googulator: i tried with literally -DAAAAA

<webczat>and it crashed same way

<Googulator>that seems to be a problem with your build of mes

<Googulator>or a regression since 0.23

<webczat>Googulator: it might be.

<webczat>also it's parsing stage

<webczat>not compiling stage

<webczat>and now, bunch of "undeclared function stpcpy/strdup", then undeclared ENOTSUP

<webczat>i'd probably give up with directly compiling make with mescc at this point. but unsure

<janneke>hmm, mes lib c does have strdup, but fails to add a prototype

<janneke>(not sure why that would be a problem)

<webczat>janneke: mescc seems not to have a declaration in headers. grepped for it

<janneke>what version of make are you compiling?

<webczat>janneke: 4.4. so newer than recommended.

<janneke>ah right

<janneke>yeah, because bootstrappable-tcc also uses mes c lib, so it would have the same problems

<webczat>also stpcpy is really not present. the problem is that ./configure didn't detect it and didn't error out. it should #define a replacement...?

<janneke>there's no stpcpy, so yeah that might be a configure bug

<webczat>janneke: if strdup can be found it's okay. it's stpcpy which is a real problem as it's not present

<webczat>janneke: so let's assume I want to build a bootstrappable tcc instead. where to find it? I find something tagged mes-0.12 but that seems to require some files I don't have?

<webczat>i assume i can't build non bootstrappable tcc without make and without patches

<janneke>=> https://gitlab.com/janneke/tinycc

<oriansj>well one doesn't require make to build anything

<webczat>so i found a good one. but what tag/branch?

<janneke>you'll want branch mes-0.25

<oriansj>and patches are just one way of altering the source code to the form required to be compiled.

<webczat>oriansj: but you have to redo processing make does if any, etc

<webczat>janneke: so such a branch exists... good to know I am more blind than I thought :D

<oriansj>webczat: well the correct set of instructions do need to be executed and make is usually the simplest way of expressing that but make does not include any magic.

<webczat>oriansj: true. not arguing with that. it's the difficulty level that's a problem. expectations you don't know about, failure to properly interpret what a makefile does to redo it... etc

<webczat>janneke: ahh it's a branch, not a tag... uhm

<oriansj>webczat: well you can always log the commands executed by make and then use that as a guide for the set of individual commands needed.

<webczat>oriansj: yep...

<webczat>btw what's this ENOTSUP thing? compiling make gave me an error about missing variable ENOTSUP. which probably means it's missing a #define, which... is an errno?

<webczat>also if that's happening, curious if make will fail to compile on tcc because of that

<janneke>ENOTSUP is currently not supported, but you may try using -D ENOTSUP=95

<sam_>ENOTSUPNOTSUP

<sam_>(sorry)

<webczat>janneke: we'll see, already switched to trying to build bootstrappable tcc.

<webczat>sam_: yeah. a separate errno for that :)

<webczat>janneke: where can I find instructions?

<janneke>hehe

<janneke>webczat: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm#n551

<janneke>or see the bootstrap.sh script

<webczat>looking at it but my first try failed :)

<webczat>as in bootstrap.sh

<webczat>what does it mean when I see a message like can't find boot5.mes? mescc launched standalone still works

<janneke>that means that MES_PREFIX is not set or has the wrong value

<webczat>might something not be installed after mes's install.sh?

<webczat>I've once seen that removing sources of mes make mes stop working after bootstrap/build/install

<stikonas>you don't need make to build tcc

<stikonas>tcc can be built with -DONE_FILE=1 and then it includes everythign else into tcc.c

<stikonas>here there are some low level steps to build it https://github.com/fosslinux/live-bootstrap/blob/master/steps/tcc-0.9.26/pass1.kaem

<stikonas>but if you have shell, you can just use bootstrap.sh...

<janneke>webczat: you could try uncommenting MES_PREFIX=${MES_PREFIX-mes} in bootstrap.sh

<webczat>janneke: now i suspect that something was literally not copied to the mes prefix. hmm

<janneke>this is one of the main reasons why the bootstrap is documenten in guix

<janneke>*documented

<janneke>you can be certain that what's described in commencement.scm just works

<webczat>yep

<webczat>how to get what's the default modulepath of my mes?

<webczat>i think MES_PREFIX itself is correct so need to check

<webczat>ok I'm further... it says there is no config.h...

<webczat>note the scm files aren't that easy to parse by me so

<janneke>yeah, you can create that by running ./configure

<janneke>see the (replace 'configure ...) stage

<webczat>running!

<webczat>is it going to compile with itself after first bootstrap.sh run?

<webczat>s/after/during/

<webczat>ah the answer is no :)

<stikonas>bootstrap.sh already runs multiple self-rebuilds

<webczat>stikonas: i mean bootstrappable tcc's, not mes's

<stikonas>yes, I also mean bootstrappable tcc

<stikonas>on x86 it builds tcc-mes tcc-boot0 tcc-boot1... tcc-boot5

<webczat>i didn't see it running the build more than once

<webczat>okay redoing. maybe did something wrong

<webczat>but it only built tcc-mes

<webczat>my bad... it works as intended

<webczat>what's the difference between final bootstrappable tcc and the normal tcc except version? is it beneficial to build normal tcc or it's basically same at this point?

<webczat>well if i need to rebuild this tcc multiple times then probably the normal one is better

<stikonas>webczat: it's an older snapshot

<stikonas>bootstrappable tcc was branched off 8 months or so before 0.9.27

<webczat>mmmh

<stikonas>and rebuilding multiple times servers 2 purposes

<stikonas>1. some stuff like flots and (on 32-bit arches only) long long is #ifdefed and not enabled

<stikonas>and further rebuilds are done to reach a fixed point in output checksum

<webczat>i know why multiple stages exist, gcc does the same but three stages and without disabling functionality on first stages

<webczat>it's like elf verification

<stikonas>well, in principle only 1 stage with disabling functionality is needed

<stikonas>bootstrap.sh does it one by one but that's probably just leftover of bringup efforts by janneke

<stikonas>you only need 1 stage with disabled functionality

<stikonas>and then normal 3 stages

<webczat>yep

<webczat>curious when tcc will not require disabling functionality when built on mescc if at all

<webczat>or even tcc would be skipped completely but it would probably be slow

<stikonas>yeah, mescc is probably too slow to build more stuff

<stikonas>as for not disabling functionality, somebody needs to work on it

<stikonas>but almost nobody is working on mescc

<stikonas>it mostly sees just new arch enablement work

<webczat>mhm

<stikonas>but yes, it would be nice to not require bootstrappable-tcc

<webczat>why is float and longlong so hard? as in... longlong on 32 bits needs manual support, floats not sure, you could do forced softfloat everywhere for this?

<stikonas>long long is free on 64-bit arches

<stikonas>and in fact we have to build the very first build with them enabled

<stikonas>not sure about floats too...

<stikonas>janneke: any insights about floats?

<stikonas>there might be a few other things that are disabled

<webczat>unsure if softfloat is easier to do than hardfloat. and you don't really need hardfloat if the goal isn't to produce good as in fast/optimized/whatever output, but to be able to build gcc or tcc in this case which will immediately switch to better code on stage2

<webczat>tcc itself is probably not optimizing? isn't that what makes it so exra fast?

<stikonas>yeah, tcc is single pass

<stikonas>and does not do much optimizing

<stikonas>though it emits a faster machine code than M2-Planet or mescc

<stikonas>tcc is also a small program that directly emits machine code

<stikonas>so it's even somewhat faster than gcc -O0

<stikonas>though that fact makes working with tcc hard

<stikonas>(as a developer)

<stikonas>tcc coding style doesn't help either

<webczat>hmmmm

<janneke>stikonas: why mescc doesn't have floats?

<stikonas>well, I'm just not familiar with that, I guess just nobody implemented those?

<janneke>we didn't need them

<stikonas>since it was easier to patch them out of tcc

<janneke>yeah

<janneke>also, having float without double doesn't make much sense

<janneke>so implementing long long first would make more sense, i think

<janneke>a couple of places assume values can be hold in a register on a stack frame

<stikonas>well, at the very least long long works on 64-bit bootstrap :)

<janneke>:)

<stikonas>though of course tcc-mes on x86_64 segfaults...

<janneke>:(

<ekaitz>janneke: did you see the comma operator error?

<ekaitz>i'm making a test for it rn

<webczat>mm

<webczat>make-4.4 has numerous build problems on mes libc. make-3.82 also does because it yells about missing putenv

<webczat>but it's the only problem I think

<webczat>what do you do with this? i changed it to setenv

<webczat>make 4.4 has problems like: mktemp not declared in stdlib.h, putenv, siggetmask/sigsetmask/flock.../O_CLOEXEC

<webczat>and tmpfile

<webczat>most of these fail at link. especially weird case is that sigsetmask is probably being detected by configure

<webczat>ahm again is in lib and not headers but siggetmask isn't

<ekaitz>webczat: https://lists.gnu.org/archive/html/bug-mes/2024-02/msg00005.html

<ekaitz>hopefully we can fix that in the future

<webczat>most of these are probably trivial

<webczat>some are less so

<ekaitz>what you are doing right now is interesting because it lets us find improvements for mescc

<ekaitz>if you can document them with simple reproducers, that would be great

<webczat>ekaitz: i am doing my thing without documenting anything live, so unsure if I will remember things long enough. it's probably much easier to just build mestc and bootstrappable tcc, then try to build make-4.4.

<ekaitz>yeah that's what we do now

<ekaitz>maybe not that version

<ekaitz>let me check

<webczat>tcc gives nicer errors, so generally poking at the sources shows the problem

<ekaitz>at least, we have a new test for the comma operator now

<webczat>ekaitz: you do 3.x ... 3.82? not sure, close. but it also doesn't compile because of putenv.

<webczat>ekaitz: this is the only one really requiring a reproducer. considering I gave up on direct compiling make with mescc, othervise there would be more of that. although... the error about missing ENOTSUP was in both mescc and tcc so... that's a libc problem, i didn't go further

<ekaitz>3.82

<ekaitz>ACTION just checked

<ekaitz>if you have the chance to make some reproducers, i'll appreciate them

<webczat>that's what I remember. it fails because of missing putenv. when I see something like this I immediately grep the whole /mes and see... nothing :P

<ekaitz>haha

<ekaitz>we need more people coding in mes

<ekaitz>if we really want to remove tcc in the future

<ekaitz>webczat: maybe you?

<webczat>ekaitz: these are obvious. i mean things that aren't present at all or are missing from headers. so not sure what would the reproducer show. one could just try to compile make 4.x and then repeatedly get all the errors, because they are pretty obvious when not trying to use mescc to compile. that way i kinda almost managed to compile it

<ekaitz>hehe

<webczat>ekaitz: i am not really competent in compilers. and have never seen scheme. I'm more likely to try to fix these libc bugs or at least some of them than to touch compilers atm

<ekaitz>meslibc has bugs too, of course

<ekaitz>if you can help there, that's also welcome

<ekaitz>and i'm not competent in compilers either

<webczat>this one is exclusively missing functions or missing prototypes

<ekaitz>yeah

<ekaitz>we found that kind of stuff too

<webczat>ekaitz: i haven't written any parser in my lifetime. :P

<ekaitz>(me neither)

<webczat>ekaitz: most of these are indeed trivial. I would be most afraid of flock because it's completely not present and.... something I forgot about

<ekaitz>the missing functions and stuff like that will probably appear in tcc too

<ekaitz>if you are using the same libc, which you should be

<webczat>ekaitz: they did

<webczat>realpath, dl*...

<ekaitz>yeah

<ekaitz>that realpath thingie...

<ekaitz>webczat: we have a patch for that

<webczat>nice

<ekaitz>it's a tcc patch to clean it

<webczat>dl* is problematic because not sure if it doesn't try to actually open elf files with it. and you don't have a dynamic linker.

<ekaitz>tcc-mob uses realpath, there's a patch to remove it

<webczat>what's mob? i know this branch is called mob but

<ekaitz>yeah, that one

<webczat>yes i tried to compile tcc-mob

<ekaitz> https://github.com/ekaitz-zarraga/tcc/commit/7805d70d53a45880b99e1fa40ab0d3fb1641346d

<webczat>could disable pthreads, could kinda patch out usage of -lm but directly in Makefile, and only dl* and realpath remained.

<ekaitz>i should change the commit message and remove the `riscv:` prefix

<webczat>ekaitz: it doesn't give me much without dl*...

<ekaitz>that's realpath

<webczat>although there is some *IS_NATIVE macro that should be able to disable it

<webczat>ekaitz: ik

<ekaitz>also, we build a bootstrappable tcc first

<ekaitz>and then tcc-mob with it

<webczat>ekaitz: i have a bootstrappable tcc working

IRC channel logs

2024-02-27.log