<oriansj>possibly; would take alot of digging <oriansj>right now at 3396lines of code and counting <fossy>./configure --enable-static=yes --enable-shared=no <fossy>libguile/guile: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e28ab7a1930166167cab0d0a4e71e3f63e4abbc4, for GNU/Linux 3.2.0, with debug_info, not stripped <oriansj>a better question why bother with autotools when freaking bootstrapping? <oriansj>It is like an elementry school teacher telling you that they always wear a condom in class... <fossy>because we need guile for the boostrap right now? <oriansj>fossy: you can pregenerate the build flags when bootstrapping <fossy>well all i am trying to do is get a statically linked guile binary seed <oriansj>aka, gcc foo.c ... -o foo is rather trivial when you know gcc is going to freaking be there <fossy>but idk what gcc foo.c .... -o foo is right now <fossy>but that is probably what i will end up having to do <fossy>rather than trying to deal with freaking autotools <fossy>and i was using autotools for that <oriansj>I know because I wrote it when trying to build mes.c with gcc <oriansj>what was really a kick in the teeth was when I finally made mes.c buildable via gcc; it exploded from "500 lines of simple C" to 4726lines of macro heavy C (not even counting the functions imported) <fossy>what made it explode like that?! <oriansj>mes.c depended upon snarfing to build <dddddd>oriansj, All tests pass here. Feel free to test and cherry-pick this commit from my M2-Planet repo: "aarch64: do not generate a wasteful stack anymore" b2ece54864fc535f60e93d66561149d966374618 <oriansj>snarfing converted it into a much larger program with lots of expansion done <oriansj>It is one of the reasons I abandoned mes.c; too much wasn't written by human hands <oriansj>dddddd: no, thank you for improving M2-Planet ^_^ <fossy>why are build systems so crappy <oriansj>fossy: because they are designed to forgive bad platforms of their sins <oriansj>You must suffer, so that they can be redeemed <fossy>but you said kaem is the worst build tool <oriansj>It is literally the worst build tool I could make <fossy>anyway for the time being im just going to not include a guile in the repository and get anyone who wants to use gcc-seed before mes m2 is ready install guile themselves <oriansj>but it is sadly better than many others <fossy>and then when mes m2 is ready that problem will be solvrd <oriansj>kaem can look up binaries from the PATH variable <oriansj>we pulled that out of kaem-minimal but if you put echo "foo" in a file and do kaem -f file <fossy>yeah thats what I was going to do <oriansj>and I'll be updating kaem.c to do the right thing when execve fails <oriansj>in man execve it clearly states that execve should not return unless error <oriansj>however when I change it to return exit_failure; calling it always returns? <oriansj>So just running ./bin/kaem --verbose --strict -f foo <oriansj>errors out; however when opened with gdb; no issues <oriansj>fossy: you can verify it by changing line 348 from _exit(EXIT_SUCCESS); to _exit(EXIT_FAILURE); <oriansj>or any other commands you know will not fail <oriansj>but open it with cgdb (or just plan gdb) and break at the fork() <oriansj>single stepping results in everything being fine <oriansj>now 0 meaning wait for any child process whose process group ID is equal to that of the calling process. <oriansj>in theory there should be no other processes in the process group ID <oriansj>changing it to a 1 meaning wait for the child whose process ID is equal to the value of pid <oriansj>looks like I had an off by one error in kaem-minimal.M1 <oriansj>and I am currently merging your work with the newest version of kaem-minimal <oriansj>in weird news after the merge AMD64's ../bin/kaem --verbose --strict --file mes-m2.kaem broke <oriansj>it appears mescc-tools-full-kaem.kaem has been truncated <oriansj>no worries, it'll be resurrected shortly <oriansj>bootstrap-seeds is now having a proper binary <oriansj>waitpid(f, &status, 1); works with gcc but waitpid(f, &status, 0); works with M2-Planet <oriansj>it acts like it isn't waiting for anything at all <oriansj>if I do waitpid(f, &status, 1); M2-Planet build runs crazy then ../bin/kaem is used <oriansj>but if I do waitpid(f, &status, 0); M2-Planet build works fine but gcc output aborts hard after doing echo "foo" <fossy>variable substitution coming soon to a kaem near you <oriansj>I hate to have to do that but It looks like I don't have much of an option <oriansj>#define waitmode 1 && //CONSTANT waitmode 0 will certainly do the trick <oriansj>I just wish to know why the behavior is different <oriansj>If you single step the GCC binary it calls waitpid with the pid instead of 1 <oriansj>with rdi and rdx having the exact same value <janneke>oriansj: mescc-tools WTF?: if [ -e /usr/bin/sha256sum ]; then *janneke goes to patch guix build recipe <janneke>i probably should not complain when i get aarch for free, which i need <janneke>but i've been fighting hardcoded /usr/* checks in configure and build systems for > 25y <janneke>it's so frustrating that the concept of having multiple unix roots still hasn't landed in our collective awareness :-( :-( <oriansj>janneke: patches are always welcome ^_^ <oriansj>I can't do everything perfect; way too much on my plate these days <oriansj>it certainly has landed but I just don't remember the correct way to deal wih it when one is using a 737byte shell <oriansj>I also have /usr/bin/env in my guix config <oriansj>morning ng0 we have a new 737byte treat for those bootstrapping <oriansj>fair I guess given that v0.4.0 occurred on 2020/02/02 <oriansj>fossy: and I should have the kaem-optional-seed.hex0 done today (as every binary deserves atleast a hex0) <janneke>oriansj: yeah, perfection comes from many eyeballs and many patches <janneke>and perfection is many different things to many different minds ***ng0_ is now known as ng0
<ng0>well i still need to catch up with the packages.. and do some mental balancing and discussions on the scope of reproducibility in pkgsrc. i have other tasks lined up before that <ng0>janneke: i don't know if i was (train/jet)lagged earlier this week and already mentioned it, but i was sitting in your talk and found it very inspiring and good. maybe for the 2 or 3 odd users porting Guix also gets easier once there's almost no binary bootstrap left (because it seems as if there's the expectation that I will port Guix to NetBSD/amd64 native by at least 2 people o.o) <ng0>once I get there, I think I need to talk to Guix again for scope of OS support. ideally there doesn't even have to be much initial porting because of our linux emulation, but we'll see how this works out. my many other projects and hobbies complain, but the hacker in me wants it just because it can be done. <janneke>ooh, guix on NetBSD, that would be nice <janneke>have you seen that some initial scaffold work has been done to port mes to FreeBSD? <ng0>i mean it fits the userbase, because some of our users are weird like that, and there's no grudge against GNU contrary to what more loudly rambling people of other projects say. i prefer learning from each other and working together <janneke>i worked with h4nnes on an initial scaffold; really only ELF headers for freebsd in mes; he was very enthousiastic about bootstrapping and i also wanted to venture into *BSD <ng0>i see.. interesting :) <janneke>so what's in mes now is really more of a teaser than anything else <hannes>.oO(and hannes has been procrastinating with lots of other things to continue on the mes / FreeBSD front) <janneke>hannes: ah, sorry for inserting a `4' into your nick ;-) <hannes>it is not that i lost interest, it is more that i keep myself busy with other things ;) *janneke is playing with a pinebook pro and ARM stuff <oriansj>ng0: I'd love to help get the bootstrap pieces working on the *BSDs <hannes>janneke: i suspect sitting somewhere a weekend/week on that with others would help to focus on bootstrapping mes.. ;) <ng0_>i'm not quiet sure if/how/etc this can find its way into NetBSD though, I'd have to talk to the right developers. packaging for pkgsrc for now (and porting this way) is better for now. and then there's the precondition that anything which might land in base must have at least a couple of years (or some time) of proven maintenance (and, not sure about this one, work on all tier 1 ports) <hannes>ng0_: i at least managed to upstream some nyacc (a dependency of mes/mes-tools) patches (use $MAKE instead of make) -- that has been merged to master (not sure whether there has been a release since) <ng0_>i think freebsd has a similar acceptance process, right? no idea if you specifically target freebsd base in the near/far future or only ports <hannes>ng0_: FreeBSD ports is what I target. I don't know the policies about the base system, but they look rather strict. <oriansj>ng0_: Gnu Mes and stage0 have been actively worked on since 2016 <ng0_>i know. this part wouldn't be questionable <ng0_>so let's say we have this in NetBSD. would you accept patches for adding support for all kinds of architectures we support (and can find people for to still test it on)? <oriansj>one can not have a universal bootstrap, without accepting help getting it working everywhere <oriansj>To be honest, I think any efforts the guix developers take to get guix working on the *BSDs and microkernels like (Gnu Hurd, L4, etc) will end up making it much more independent of many assumptions about hosts; hopefully resulting in a longer living project. <hannes>^^ this is exactly my experience from a different angle -- having a "unikernel" OS [https://openmirage.org] initially developed for Xen, then ported to ARM32, and afterwards KVM, followed by VirtIO, FreeBSD BHyve, OpenBSD VMM, ... -- esp. of curiousity may be solo5 (https://github.com/solo5/solo5) which "abstracts" over kvm/bhyve/virtio, but also genode and muen, plus recently seccomp -- a pile of <hannes>(imho very readable) C code with only few #ifdefs <oriansj>hannes: exactly, the easier to becomes to port guix to new Operating systems; the better long term survival odds guix has <oriansj>We must keep a careful eye on the Anna Karenina principle when doing systems planning ***ng0_ is now known as ng0
<dddddd>OK, let's look a bit more that half-finished M1.scm at slow-utils. ***jelle is now known as blahaj
<oriansj>dddddd: once it is done janneke and guix will have a single binary only scheme, only bootstrap <oriansj>unless guix has some other hidden binaries it depends upon we need to know about ***blahaj is now known as jelle
<fossy>oriansj: nice, how goes the hex0 kaem? <fossy>file_print is making buffer overflows and rewriting a variable that it dosen't even reference <fossy>sorry, no numerate_number is <fossy>oriansj: M2-Planet does not do any look-ahead compiling optomisations does it? <fossy>hmm, i think this is an off-by-one error somewhere <fossy>because it only happens with 1-length strings <fossy>strings are terminated with a zero afterwards right? <Hagfish>that sounds like something that fuzzing could have found, but i'm sorry i can't be more helpful than that <fossy>Hagfish: fuzzing only finds segfaults and hangs <Hagfish>the mention of buffer overflows / rewriting variables made me think of memory safety <Hagfish>there are sanitisers that find that sort of thing, right? <Hagfish>"(You can also use AFL_USE_MSAN=1 to enable MSAN instead.)" <Hagfish>that might be the approach i was thinking of (not that i've ever tried it or recommend it) <dddddd>cc is just one char, how can be zero terminated? After it, in memory, is whatever, if I'm reading the code correctly. <dddddd>I'd try calloc(2, ...) for cc[1] == 0 <dddddd>Almost sure no look-ahead optimizations exists in M2-Planet. <dddddd>The only optimization I remember is eliminating a double-return, which in some sense is not optimization, but undo some step because it doesn't look ahead. <fossy>The behaviour occurs with "full" strings <fossy>That are initialized by setting each char individually <fossy>And so it spills over until there is a zero <fossy>Solution: when doing that, allocate one more than characters <fossy>And set array[length - 1] = 0 <dddddd>Right, always one more than chars expected. About terminating... calloc does that for you (initilizes everything to 0) but it's fine to be explicit, making sure you terminate the string with zero. <fossy>dddddd: if you fill up the string, manually, there is no gurantee the next byte will be 0 <fossy>as the next byte is outside the allocation <fossy>and the way most string functions work is that they have no regard for string boundries outside of a terminating 0 <dddddd>It's zero if you don't overwrite the one calloc put there, at the end (on the plus one byte). <dddddd>char* cc = calloc(2, sizeof(char)); cc[0] = 'h'; <dddddd>Two bytes allocated for a one char string. cc[1] is zero right now, per calloc semantics. <dddddd>For "hi" instead of "h" --> char* cc = calloc(3, sizeof(char)); cc[0] = 'h'; cc[1] = 'i'; <dddddd>cc[2] is zero, so well terminated "hi" string. <fossy>you need to allocate length plus 1 <oriansj>fossy: M2-Planet does not do any padding on allocation. Aka, if you ask for 1 byte, the next allocation will be exactly after it. That said dddddd is correct in the only "optimization" is for double returns (It just slightly reduces binary sizes) <oriansj>In short undefined behavior that works "fine" in GCC and Clang break because you are not properly terminating your strings. <oriansj>M2-Planet assumes you know what you are doing and gets out of your way. <fossy>it was simply a silly mistake on my part <oriansj>So if you tell M2-Planet, you want to rewrite your program while executing to do polymorphic programming, it is easy to do <oriansj>fossy: Should be done in the next couple hours. <oriansj>hex0 programming is always slow as shit; Like doing art with sand <oriansj>I do it from scratch to keep me honest <oriansj>Hence, why I do this sort of so rarely. It is a massive pain to write a 737byte binary in hex0 <oriansj>hex1 and hex2 isn't so bad because the offsets are automatically calculated for you <oriansj>I can easily do 4974lines of M0 in a day or 1300ish lines of hex2 in a day <oriansj>but I rarely write hex0 programs more than 400lines long and they take all day <oriansj>x86/hex1_x86.hex0 is only 329lines long