IRC channel logs
2021-02-15.log
back to list of logs
<stikonas>pder: so maybe it's best to first get binutils and ar working? <stikonas>because more stuff might be slightly broken, not just stdio <stikonas>I guess we should look for some library to regenerate autotools files... <pder>do tcc and musl need to be rebuilt? For musl, the configure script appears to be hand written <stikonas>pder: and yes, we need to rebuild it without that hacky patch <stikonas>although, if we have binutils by then, we can even build libc.so and switch to dynamic linking <stikonas>pder: so I briefly looked at autoconf problem <stikonas>not sure what exactly causes it, but must be something minor <stikonas>(it creates configure that is zero size) <stikonas>but when I ran it with bash +x and then manually ran m4 command that it was running, I've got proper configure script printed to stdout (which I could redirect to configure file) <pder>so you are still having issues with my latest patch? <stikonas>but autoconf problem is probably somethign else <stikonas>maybe this step fails "exec 4> configure" <stikonas>pder: oh, maybe exec also has somethign to do with your patch... <stikonas>anyway, I'll probably try some other day <pder>The goal of the patch was for it to call the methods in Exit() in src/exit/exit.c. Before they appeared to be noops <stikonas>oh, actually, it might be because of awk crashing <pder>didnt you say something about awk needing some files in a share directory? <stikonas>so I think to summarise the state of things <stikonas>1) we have some problems with stdio but you have a patch that might fix them <stikonas>2) gawk crashes on non-trivial programs, this needs investigation <stikonas>3) perl needs some further work to generate opcode.h <stikonas>and then I think we shoud be able to run autotools <stikonas>(my initial testing indicates that miniperl is capable or running those even if it's not full perl) <stikonas>so we can postpone full perl bootstrap till a bit later <pder>do you have an example of what makes gawk crash? <stikonas>(this works though echo test | gawk '{print "Hello World"}') <pder>ok, I can reproduce. Thats with my latest musl patch <stikonas>pder: oh, it might be interesting if you can test miniperl with your patch <pder>I have it. I'll cherry-pick it on to my branch <stikonas>perl ./keywords.pl was producing truncated files... <stikonas>we don't really need to run those at this stage (it was just my test to see if perl works) <stikonas>but anyway, I think we are almost done with writing manual makefiles <stikonas>pder: by the way, some projects don't seem to have Makefile.am files, any idea why? <stikonas>although, that Makefile.in file looks quite readable, so maybe it is handwritten <stikonas>and then configure just populates it with correct variables <stikonas>oh, maybe we should populate some devices too... <pder>So I just ran perl keywords.pl <pder>last line is #define KEY_y 240 <pder>perl opcode.pl seems to create a complete opcode.h <OriansJ>file with the exact same checksum went from functional to failing after restart of VM <OriansJ>and a relative branch became an absolute branch?????? <pder>stikonas: gawk no longer crashes after adding -DHAVE_STRING_H <pder>Checking to see if anything else is missing <OriansJ>looks like PPC64 suffers from the exact same byte ordering problems as ARM and AArch64 <OriansJ>documentation says [6bits opcode] [24bit immediate] [2bits mode] -> reality [6bits immediate] [2bits mode] [16bits immediate] [6bits opcode] [2bits immediate] <OriansJ>fortunately the immediates for relative branches shave the last 2 bits off the displacement and those 2 bits end up being only half useful here for us. <OriansJ>one of them makes the instruction branch to absolute addresses and the other indicates to set the link register with the PC. <OriansJ>so ^~foo and ~foo can map without issue to the setting/not-settting of the link bit and 24bits of displacement <OriansJ>we will still need to encode 2bits of immediate as either {00, 01} positive, {10, or 11} negative displacements with the opcode but I guess we could just pretend an extra 2bits of opcode, use 00 and 11 to express forward and backward jumps <OriansJ>I'll need to update my powerpc displacement calculations in hex2 but dftxbs3e hopefully that will not be a problem for you <OriansJ>interesting displacement is measured from the beginning of the instruction. <pder>stikonas: I made a few changes to the gawk Makefile and have something that seems to be working at least for basic stuff. There appears to be something wrong with floats and/or displaying them with our toolchain. <pder>I pushed it to a branch wip-gawk <OriansJ>dftxbs3e: I was just about you email you <OriansJ>a more advanced displacement test is now available <OriansJ>hex2 --architecture ppc64le --little-endian -f 1185516 --base-address 0x10000000 -o foo && ./foo || echo $? <OriansJ>with 0x10000080 being the entry if you want gdb to single stepi it <OriansJ>using latest mescc-tools commit ca1fa0a50b63e38f0d9b00bc94418918dc794227 <OriansJ>now both forward and backward branches should always work correctly <OriansJ>if the jump is wrong, it'll loop forever or segfault fast <OriansJ>so ^~forward_link 48 and ^~backward_link 4B vs ~forward_nolink 48 ~backward_nolink 4B should be able to be added for as much complexity as you would want. <OriansJ>if you do gdb foo; b* 0x10000080; run layout regs; si (a few times) <OriansJ>You should see assembly matching the hex2 comments and the jumps doing what the hex2 suggest. <OriansJ>it'll be added to mescc-tools after the next release (with several more enchancements) <OriansJ>although I find it odd that IBM's assembly doesn't do r0 r1, etc but instead just 0 1 etc <fossy>gforce_d11977: thank you very much for that work on sha256sum <fossy>i modified it slightly to take multiple arguments for generation and use a sha256sum file (like sha256sum -c does) <fossy>produces close-to-identical output with coreutils <gforce_d11977>fossy: very good, that was on my list for today, so i can do other things 8-) <fossy>gforce_d11977: oops sorry hope I didnt duplicate any work <stikonas[m]>pder: nice work! Changes look good. Are you making PR soon? <stikonas>pder: so with your two PRs autoconf is also working <stikonas>that means we only need to recreate perl's opcode.h, and manually install automake/autoconf <stikonas>and then I think we'll be able to stop manual makefiles <pder>whats the issue with perls opcode.h? <stikonas>so until we have miniperl, we can't regenerate it <stikonas>but we can write some script that generates the same thing... <stikonas>or at least generate something that's good enough to create miniperl (if it can then regenerate proper opcode.h) <pder>I am confused. I just ran a build including your perl branch and miniperl is built and can generate opcode.h <stikonas>there was a similar issue with keywords.h but I've already regenerated it yesterday <stikonas>oh, because it uses upstream generated opcode.h <pder>so you want to be able to delete these versions in the tarball and recreate them? <stikonas>yeah, same as with other generated files.. <stikonas>although, I have less problems with opcode.h <pder>does miniperl require these files to build? <stikonas>it might be possible to recreate it using sed/awk/bash <stikonas>especially with awk we can do qutie a bit of stuff... <stikonas>pder: that's also the reason why we chose perl 5.000 <stikonas>anything newer (even 5.001) need another script embed.pl <stikonas>but in 5.000 it uses bash script embed_H.sh <pder>stikonas: opcode.h appears to be a minor pain but doable without perl <stikonas>are you looking at it or not really (to avoid any duplicate work) <stikonas>but indeed, I don't think it would be too hard,,, <stikonas>well, once fossy merges your other PRs we can use gawk... <pder>not really. I took a stab at trying to compile binutils 2.14 with what we have so far. Suprisingly tcc-mes makes it farther than tcc-musl <pder>I used guix commencement.scm as a reference <stikonas>for musl, maybe we need to tweak them a bit... <stikonas>if musl, maybe evne newer binutils would work better? <pder>I kept running into "too many basic types" errors from tcc <stikonas>but strange, why would it work on guix and not here... <stikonas>tcc-mes should be basically where guix is <pder>that error was from tcc-musl. tcc-mes did not give that error, but died somewhere else that I cant remember <stikonas>I briefly looked at perl's metaconfig's README, it's also not particularly nice :( <stikonas>although, we don't really need ir right now <stikonas>pder: ok, I'll start working on opcode.h, so don't do it at the same time... <stikonas>maybe even slightly shorter than perl code... <stikonas>perl code just looks at the table and prints columns with some prefixes and suffixes <stikonas>so something like awk -F'\t' '{print "\t\""$2"\","}' data <stikonas>so I think in two days perl might be already merged into live-bootstrap <stikonas>ok, definitely not too bad, 5 out of 6 are done. last one might be a bit more complicated but should be doable