<aggi>and, who cares about this? <aggi>i mean, the benefits are obvious, and it's not some shallow promises of theirs: "Minimal bootstrap dependencies" <aggi>"Fast builds that are 100% reproducible" <aggi>"ISO C conformant", cproc/qbe <stikonas>I'm not familiar with oasis linux, so can't comment... <aggi>GNU-buildsystem independent build/package-management! <aggi>but: "This involves considerable up-front packaging cost" yes, and that's not only problem <muurkha>abolish the guildsystem! right to work! <aggi>well, currently i am tracking/patching 300(!!!) ebuilds already, to keep the gentoo profile for gcc47/c-only <aggi>i can't, and i don't want to move all this to oasis anyway <aggi>and, some unavoidable blockers won't be avoided anyway, unrelated to Oasis <stikonas>it basically depends on what the goals of your project is <stikonas>what is the target audience, would they care what is the base, etc... <aggi>it's not some specific project goals, it is minimum acceptance criteria, including a clean bootstrapping path <aggi>what are you working with? GUIX? <muurkha>a project's minimum acceptance criteria are among its goals <stikonas>oriansj: if I'm reading it correctly (I'm not sure yet), SizeOfRawData might have to be multiple of 512, though I'm confused why it worked for earlier binaries... <stikonas>maybe there is some limit, i.e. 4 KiB under which it doesn't matter <stikonas>oh, we probably need to deal with other fields, e.g. SizeOfImage <stikonas>ok, I can increase SizeOfImage field in PE header to 1MiB and it seems to work <oriansj>stikonas: probably good enough until after M1+blood-elf is properly bootstrapped; then we might need to figure out the correct solution. <oriansj>stikonas: but it can be used to generate info that we can't hard-code in the header <oriansj>which in the case of UEFI might end up being most of the header <stikonas>yeah, possibly, I don't have that good recollection of how blood-elf works <stikonas>but I guess it's just smarter header/footer generator <stikonas>anyway, I think I have some bugs in cc_amd64.M1 <stikonas>builds simple stuff but gets stuck on M2-0.c <stikonas>so I need to go over the file once more... <oriansj>well cc_* doesn't have any bit that loops without moving forward a token forward; so it should never get stuck but bail quickly on bad input <oriansj>so only syscalls can stall its progress <stikonas>we can still jump to unexpected position <stikonas>and then it's basically undefined behaviour <stikonas>I actually found a couple of issues, but there are probably more <stikonas>so we were falling through to another function <stikonas>(which would of course cause bad stack and on next return it's jump to somewhere "random") <oriansj>ooh, unbalanced stack issues are the worst to debug <stikonas>anyway, I'll just go over the file once more now paying more attention <stikonas>rather than quickly machanically porting GAS to M1 <stikonas>that first issue where UEFI refused to start cc_amd64.efi was scarier initially, but luckily I've figured out which PE field was causing the problem <oriansj>UEFI just seems like the worst possible development environment <stikonas>I think one can wire in gdb, but it's not trivial <stikonas>though maybe it would work easier for us since we are fully position independent <stikonas>and I don't think I'll need it here either <oriansj>well, you are quite capable so I don't doubt that. <oriansj>hard bet that it is a generated string <muurkha>yeah, I don't think he typed 18000 pages of lambda-calculus by hand <muurkha>I think he modified Rui Ueyama's 8cc to target the lambda calculus <oriansj>and then didn't provide that source code ***ChanServ sets mode: +o oriansj
<stikonas[m]>but then what's the point of comitting 18k pages to git... Just push the script that generates it... <muurkha>indeed, committing build artifacts to source control is not a best practice <muurkha>but there are some features of github that incentivize it <oriansj>it is a massively abuse encouraging metric <jbowen>I assume they meant having a lot of changed lines on your profile <muurkha>could be? is that metric published somewhere? <stikonas>but not sure about aggregate throught all repos that you have contributed to <oriansj>stikonas: that is correct M0 doesn't have escapes but NASM does <stikonas>oh, let me check the other file, I think it's there too <oriansj>yeah, it would just cause the char \ to be checked twice <oriansj>but yeah that can be removed to save a couple cycles <stikonas>anyway, first I need to find remaining bugs in UEFI version of cc_amd64.M1 <stikonas>found a few small issues, but there is at least 1 more <oriansj>muurkha: I was thinking about this post: http://howicode.nateeag.com/data-preservation.html and there might be a way to leverage stage0 (ported to a very minimal architecture which could be described in a few pages) to enable future data recovery from media provided about 30-50MB of storage could be ensured. <oriansj>(although about 834M would be needed to preserve the full contents of live-bootstrap)