IRC channel logs
2024-01-05.log
back to list of logs
<mihi>Looking at the source of M2-Planet now, seems that it is mostly doing that already. Only that you have only one "void additive_expr_stub()" which is doing all arithmetics, unlike the usual differentiation between atom, term, factor, to get correct precedence. <mihi>Also that callback in arithmetic_recursion looks unfamiliar to me. Is that some Scheme-style tail call elimination? <mihi>so it might interfere with proper recursive descent parsing or not, probably need to try. <stikonas>hmm, does anybody know here how to check whether file exists in UEFI? <stikonas>but instead of returning error, it seems to create an empty file... <rickmasters>stikonas: assuming you set the open for READ you should get FILE_NOT_FOUND - otherwise open the parent directory and read the entries? <stikonas>well, I'll have to double check if all the parameters are set to the right values <stikonas>somehow I have an impression that something goes wrong with the values somewhere <stikonas>hmm, so somehow all the files are open as write... <stikonas>replacing if(flag == O_WRONLY|O_CREAT|O_TRUNC) with if(flag == (O_WRONLY|O_CREAT|O_TRUNC)) seems to help <stikonas>anyway, this fixes mes to print --help and --version (at the very least) <stikonas>though exposes some bug in stage0-posix... <stikonas>where it fails with ./amd64/artifact/M2-1-footer.M1 not found... <oriansj>== is supposed to have ahigher priorty than | <stikonas>M2-Mesoplanet is now failing to build stuff <oriansj>well I think I properly fixed the +/* priority; we probably will need to sit down one of these days and fix the rest (as all of the bitwise have different priorities) <stikonas>I probably won't solve Mesoplanet problem today... <stikonas>but it's always step forward and at the same time step backwards :( <oriansj>only test1000 got different checksums; so it is unlikely that I introduced any regressions <stikonas>oriansj: and in stage0-posix on M2-Planet checksum changed <stikonas>yes, but that also means were did not have wrong behaviour in other files <stikonas>anyway, I think I know why M2-Mesoplanet crashes <oriansj>well you are very good at using () everywhere it mattered <stikonas>and I probably only implemented it for files in UEFI <oriansj>a generally reasonable assumption that holds all the way up til then <stikonas>understanding the cause is usually most of the way to fixing the bug <stikonas>and then we'll have mes --help working i uefi <stikonas>oh, the bug is due to mkstemp not working <stikonas>probabl because its trying to open files in (up to now) unsupported mode <stikonas>open(template, O_RDWR | O_CREAT | O_EXCL, 00600); <oriansj>well mkstemp is a kind of ugly hack in M2libc; if we were to do the proper thing, we would be using access to identify what files already exist that match our template guesses and then attempt to open the first one available. the use of O_EXCL was to esnure if anyone else is working with a file name we guess, that we would avoid accidentially of stomping all over the contents if someone else was using it; otherwise reusing lower numbers <muurkha>I think we've talked about it in here before <muurkha>Selfie is written in a tiny subset of C called C*, and contains a compiler from C* to standard ELF RISC-V binaries for a RISC-V subset called RISC-U, a CPU emulator for RISC-U, and a hypervisor for RISC-U under which Selfie can run <oriansj>muurkha: well writing C subsets is quite easy and fun to do; M2-Planet is only 4,597 lines of Code, M2libc is around 5.6Kloc of Code; so just writing a C standard library that supports multiple architectures ends up being more work than creating a C compiler that supports multiple architectures. <oriansj>it is only when one starts having to deal with preprocessor crap does writing a C compiler get "hard"; everything else is just creating lists and reading index values <stikonas>well, but M2libc now support both POSIX and UEFI <stikonas>plus quite a few different architectures... <muurkha>oriansj: yes, but those 12k lines include not only the compiler and the libc but also the CPU and the OS <stikonas>Piraty: if it's general question just ask, others might be able to answer <Piraty>it's special to fossy, i'll state it anyway <Piraty>fossy: i see you are maintainer of some abi-* tooling of lvc . did you put it to work somewhere, auto-building the packages? <stikonas>hmm, that M2libc/UEFI fix of operator precedence mode seems to be causing a chain of new issues :( <stikonas>the latest problem is that somehow remove(name) which calls unlink doesn't work :( <oriansj>odd as that is just passing a string and if that was broken half of the tests would have failed <oriansj>would the issue be in the logic making the string which is then passed to remove? <stikonas>oriansj: not sure yet, so far in UEFI it seems to return 2 <stikonas>so the question is why did it work before that operator precedence fix... <stikonas>I wonder if it's something to do with file already being open <stikonas>but adding fclose(tempfile); doesn't make it any better, I think fclose then fails <stikonas>oh, that's because we are already closing it <stikonas>perhaps I didn't adjust paths after "cd" call <stikonas>I'm trying to remove ../amd64/artifact/M2-Mesoplanet-000000 <oriansj>try --dirty-mode to make M2-Mesoplanet ignore the remove entirely <stikonas>oriansj: well, that's kind of what happens <stikonas>when I'm building 2nd file (match.c) it ends up with part new file and part previous file <stikonas>anyway, let's see what happens with --dirty-mode <oriansj>odd as the offsets should start at zero when openning the file as just w <stikonas>and when opening right now O_TRUNC is ignored <stikonas>but that's somewhat unrelated to delete not working <stikonas>well, I guess i need to insert more debug prints... <stikonas>yeah, but on UEFI O_TRUNC is not that easily exposed... <stikonas>you have to manually set file length to 0 first <stikonas>so all files are open in just one of the two modes <stikonas>mode = EFI_FILE_MODE_CREATE | EFI_FILE_MODE_WRITE | EFI_FILE_MODE_READ or EFI_FILE_MODE_READ <stikonas>so right now whether we are passing O_TRUNC or not doesn't make any difference <oriansj>in uefi/fcntl.c you would want () around O_WRONLY|O_CREAT|O_TRUNC <stikonas>hmm, the only thing that could really break unlink is if somehow access interferes with it <stikonas>I don't close the file on failure of access()! <oriansj>umm open can return more than just null on failure <oriansj>On error, -1 is returned and errno is set to indicate the error <stikonas>I must have missed that when I switched from fopen to open... <oriansj>it'll make sense if the kernel/firmware encodes the error reason in the negative value returned. <stikonas>the problem is that UEFI doens't encode the reason... <stikonas>well, but since the problem is in access <stikonas>maybe I should try to completely rework that <stikonas>maybe it's again something in if((flag & O_WRONLY) || (flag & O_RDWR)) <stikonas>hmm, I should just encode those two options that we use <oriansj>well yeah: flag & O_WRONLY would set a bit if there is a match and true is zero <stikonas>but something more tricky might be going on <oriansj>well yes, because fdopen assumes one used mktemp to get the file descriptor <oriansj>otherwise why would one use fdopen instead of fopen? <stikonas>yes, but I'm trying to understand what breaks unlink()... <oriansj>stikonas: is it in your posix kernel where unlink broke? <stikonas>i.e. something there was relying on that flag == O_WRONLY|O_CREAT|O_TRUNC bug