IRC channel logs
2024-12-17.log
back to list of logs
<unmush>if its generated C isn't fit for human consumption, then we're not much better off than with a binary <unmush>well, it did say that tasking isn't supported, so at least it will probably have one C function for each subprogram, which is a lot better than one 10000-line switch statement <unmush>but I think that "no inter-subprogram exceptions" might be a pretty serious incompatibility <lrvick>I mean we could get the generated c and prove that it actually works, and if it does, could spend some time making it more readable as goal #2 <lrvick>I have had to do this in the past. It is not fun. <lrvick>Though, I have seen some great documented efforts of this with decompilation projects now. tooling is getting much better <lrvick>some people even using LLMs to help rename functions based on what they seem to do as a starting point. <lrvick>Thinking of projects like decoompiling Mario 64 from machine code back into human readable C <lrvick>I imagine this would be about like mrustc, except with a big head start with machine genertaed c <stikonas>well, but mrustc is properly human written <stikonas>it's C++ code that can convert rust to C <stikonas>not rust code that can convert rust to C <lrvick>Yeah. Just saying it may be easier to start with machine generated C that works as a reference and convert it to human readable, than start from 0. <lrvick>but looking into it more, it uses gnat-LLVM as the intermediate. <lrvick>so really need to see what the least bad llvm -> human-readable-c options are these days <lrvick>Honestly the generated C code is not nearly as bad as I would expect. <lrvick>and it has options to include the original ada code for each block as C comments, to help with human cleanup, function/var renaming etc <unmush>cleaning up the generated C may still be easier than trying to use Ada/Ed. I spent a fair bit of time trying that, and the error reporting consists of "Segmentation Fault". <unmush>plus it's rather unportable and has lots of bugs, plus archaic limitations (I hope the strings for all of your program's symbols, plus 2 bytes overhead each, fit in 32kB!) <lrvick>The biggest unknown are that lots of modern ada features seem unsupported by the converter <lrvick>But maybe if we get an old enough version of gnat... <fossy>uh. this is unexpected, grub requires python <stikonas>fossy: oh, so python is not optional then... <fossy>yes, and we don't need it for non-kernel-bootstrap either <stikonas>anyway, I guess for now leave out extras... <fossy>yeah, i'll just close this PR for now <fossy>stikonas: or do we want to make python an extra that is auto-enabled if BUILD_LINUX == True? <stikonas>python in principle could be useful for other things <stikonas>e.g. say I do chroot initramfs build without BUILD_LINUX <stikonas>but want python for future gentoo bootstrap <fossy>yes, and keep "--extras python" to do that <fossy>just unsure if the added complexity is worth it <fossy>i guess we want extras anyway at some point? <stikonas>yeah, this added complexity is what I was not sure about too <stikonas>it's just the question whether we want to add them now or later <stikonas>python seems far more crucial than most other extras... <fossy>ok, let's just leave it as is for now <fossy>actually, maybe give a few days, I'll send an email to a gnulib contact if i can find one <fossy>but if we don't get a reply/not a useful reply then yes <deesix>Thoughts on making bootstrapping.world the primary source of those files? <fossy>no intrinsic opposition, but would really like the files to also be available from an upstream source <fossy>even if bootstrapping.world is the "primary" source <stikonas>and we need at least some script to test upstream sources <stikonas>since they tend to disappear from time to time <deesix>Exactly, the point being that "upstream" changing stuff does not impact without notice.