<oriansj>markjenkinsznc: I could knock out a cc_knight.s in 2 hours <oriansj>It only requires me to change a dozen strings and like 2 calculations <oriansj>dddddd: I found a new segfault class in M2-Planet inputs (only made it 7 hours of fuzzing before I hit it) <dddddd>Nice. I'm looking at rough edges in my libc. exit was too clever "not reading" the argument. There were a couple of extra returns. malloc is still not detecting error condition from the syscall. chmod is empty. getcwd is missing.. <oriansj>dddddd: There will be plenty of time to clear out the rough edges in M2-Planet (I promise my cc_AArch64 port will be far worse) <dddddd>There's no mescc-tools release with AArch64 support, so I guess I'd say just >0.6.1 required somewhere. <oriansj>dddddd: you are right, we are long past due for a mescc-tools release <oriansj>Release 0.7.0 of mescc-tools is now out <dddddd>Thanks! What's the protocol to update the reported --version? I think it affects some M2-Planet tests and I guess that's the reason there's no commit along the new 0.7.0 tag. <oriansj>I guess I should have bumped the version number reported; <dddddd>oh, nevermind. The tests are running internal versions of the tools (old copies). <dddddd>I was thinking of checks like: [ "$out" = "blood-elf 0.1 ..... <oriansj>yep, only ever sync when the tools start doing something new enough to worry about <dddddd>exactly, like the incoming kaem.c <oriansj>indeed; when it uses something we previously haven't tested it will be updated and all of the tests around it updated <oriansj>I rewrote the release to update the version strings <oriansj>dddddd: shall I update the talk-notes to list M2-Planet as supporting AArch64 (because potentially we could release this weekend before janneke's talk) ? <dddddd>Sure, even if not part of a release the code will be available. <oriansj>dddddd: good, because I was hoping to make it a release (Since a new Arch is important in bootstrapping terms) <dddddd>The talk is on sunday, it seems doable. <dddddd>I'm about to rebase the new master and retest. <oriansj>just remember perfect isn't required to change the world <xentrac>ring the bell that still can ring / forget your perfect offering / there's a crack in everything / that's how the light gets in <dddddd>After adapting the scripts for test19 and test26 everything seems fine again. <oriansj>and I am updating the Current bootstrap to better match the multiarch bootstrap situation <oriansj>I was tempted to add knightpies to talk-notes markjenkinsznc but I wasn't sure if you wanted it included and if so were willing to put current status info in about it <oriansj>talk-note patches are up janneke; please let us know if you have any questions <fossy>oriansj: I will make the m2 planet tests merge worthy hopefully tonight <oriansj>markjenkinsznc: I'll tell you what, I'll try to knock out cc_knight.s, cc_amd64.s and cc_armv7l.s today before midnight (you'll love the diffs when I'm done) <oriansj>Which reminds me, I need to be sending out the mescc-tools release emails today ***ng0_ is now known as ng0
<oriansj>and cc_knight-native in C is done; (now to do cc_knight-native.s) <oriansj>and the creation of cc-minimal.c will be done shortly (as knight-native can't physically support args or envp) <oriansj>(that way stage0 can just git submodule M2-Planet and mes-m2 [and the future posix]) <vagrantc>oriansj: where can one find the gpg key used to sign mescc-tools releases? <oriansj>vagrantc: well I haven't been distributing it as you are literally the first person to ask about it *vagrantc knew github probably had that somewhere but there's no user-facing interface for it <oriansj>actually if you just replace oriansj with the user name of your choice, it will return all gpg keys they have uploaded <oriansj>just don't try to download more than 1000 in an hour or they will ip ban you for a couple days *vagrantc tries to massage the json into something gpg can consume <oriansj>darn, I got the numbers wrong for what a 16bit signed value can store <oriansj>markjenkinsznc: may I present to you cc_knight-native.s; completed in 1 hour and 38 minutes of effort <fossy>sorry I didnt get to m2 planet last night <oriansj>fossy: no worries; always deal with personal matters first, we understand <oriansj>also checkout if you do: cat test/common_knight/functions/file.c test/common_knight/functions/malloc.c functions/calloc.c test/common_knight/functions/exit.c functions/match.c functions/in_set.c functions/numerate_number.c functions/file_print.c functions/number_pack.c functions/string.c functions/require.c cc.h cc_reader.c cc_strings.c cc_types.c cc_core.c cc-minimal.c >| tape_01 <oriansj>and compare cc_knight-native and M2-Planet --architecture knight-native <oriansj>(If I have time tonight, I'll hit knight-posix too) <oriansj>vagrantc: hopefully the changes in the ARMv7l ELF header will fix that <vagrantc>testing building mes with the new mescc-tools on amd64 and i386 ... hopefully i get the same hashes :) <oriansj>The only way for a M1 file to generate a different hash is: 1) wrong arguments (little endian instead of big, etc) 2) different elf header 3) not the same M1 4) compromised binaries <oriansj>well the only change in M1's output was when we made the hex2 newline output prettier (the binaries generated from them remained identical) <oriansj>So until someone finds that --octal or --binary is broken; it wouldn't be possible for the binaries to generate a different output <oriansj>The core of hex2 is literally add 2 hex characters together and output a byte; it is really hard to justify it ever outputting anything different <oriansj>and cc_amd64 prototyped in C for stage0 *vagrantc eagerly awaits!