<oriansj>and first pass at fuzzing M2-Planet; has cleared out some obvious segfaults <fossy>calloc(max_string, sizeof(char)) when compiled with gcc only in kaem is segfaulting <fossy>with malloc(): corrupted top size <oriansj>fossy: that tends to happen when something prior write past the end of the allocation <oriansj>fossy: if you share the test, I might be able to help you find the cause <fossy>oriansj: never mind i have found the issue <fossy>buffer overflow in collect_string() <fossy>target[index] = c can overflow target when given a long enough string, as it dosent have bounds checking <oriansj>import require.c from M2-Planet's functions <oriansj>and add require(MAX_STRING > index, "reasonable error message\n"); prior to the statement <fossy>oh, thats a nice way of doing it <fossy>file_print("error\n", stderr); <oriansj>it also allows alot more catching of errors in a compact space <oriansj>(checkout mes_builtins.c to see excessive use of that) <fossy>is there a string concat function? the closest i can see is prepend_string() <oriansj>but it would be trivial to make a breakout string concat <fossy>fixed that segfault... back to fuzzing for the next (if it gets any <oriansj>fossy: well I figure if you pass 8 hours of fuzzing without anything showing up, an end user is unlikely to hit a segfault and be confused <oriansj>design for least surprise and easy recovery; keeps it easier for us to make progress. <oriansj>I'll probably start looking at M1 and hex2 tomorrow (shouldn't be too many possible there) <dddddd>IIRC M1 prints garbage at the end if the input lacks \n before EOF <dddddd>I didn't try recently, so maybe that was fixed. <oriansj>dddddd: that one has been fixed (Immediately after it got reported if I remember correctly) <oriansj>but I'll hammer on it for a couple hours tomorrow ***ng0_ is now known as ng0
***ng0_ is now known as ng0
<oriansj>looks like M1 had a couple segfaults to clear out (only did about an hour of fuzzing so much more issues possibly remain) <dddddd>just checked, the garbage is there yet <markjenkinsznc>Been awhile since I've said hi. Have been following chat logs and commit logs with interest. Tagged a quiet release of https://github.com/markjenkins/knightpies/ in July without an announce post. Now close to 0.3 release. Will save a mailing list post for 0.3.5 when I implement M1.py and M1tobin.py <oriansj>markjenkinsznc: looks like a good start <markjenkinsznc>already served as a useful tool, I have it dumping any DEFINEs used by a file, this helped me work through which instructions were present in a stage0 assembler file and in turn figure out which implementations in python I needed to look at <oriansj>markjenkinsznc: clever, probably be able to catch duplicate DEFINEs as well <oriansj>and I am guessing the M1tobin.py is to skip the hex2 step of linking and go straight to useful binaries <oriansj>(or as a wrapper around M1 and hex2 which would work too) <markjenkinsznc>exactly, though the approach of staging it through files is best when writing assembler <markjenkinsznc>by given this is in python, combining things together is pretty easy, especially as I'll have the relevant parts of hex2tobin.py and M1.py in separate functions for import <markjenkinsznc>so thumbs up for the stage0 approach of keeping assembler code as simple as possible <oriansj>markjenkinsznc: you'll love it even more when you take a look at the cc_* family <oriansj>dddddd: you are right, I missed that one (I'll have to take a wack at it) <markjenkinsznc>yep, eventually for other people's bootstrap purposes I'll have stage0_cc_x86.py which can take in multiple .c files, do the concatenating internally, interpret stage0/stage2/cc_x86.s internally as a compiler with a handle on the output, do the hex conversion and output a runnable (with exec permission) GNU_linux_ELF_binary <markjenkinsznc>and I'll be able to run that on my Power Macintosh with Mac OS X something or other and python >= 2.2 and produce a binary to bring over to a x86 GNU/Linux machine <markjenkinsznc>though it may run too slow to be practical, will benchmark first on my Raptor Computer Systems Blackbird <oriansj>markjenkinsznc: well, if you are willing to just a hair more work; you could just do M2-Planet (which would enable you later to build the kernel for bootstrapping a $ANY_ARCH GNU/Linux machine <oriansj>ask M2-Planet is just cc_x86 with more architectures, input validation and support for multiple file inputs <markjenkinsznc>was thinking that too, would use M2-Planet to compile itself to Knight and then make the assembler better commented and remove parts involving other archs, then there would be an Knight assembler version of M2-Planet that can compile M2-Planet or mes-m2 to any M2-Planet supported arch <oriansj>being a simple doubly linked list state machine, you should be able to something like 10Kloc/s in python <oriansj>or a 1 second time for a build of M2-Planet's C sources <markjenkinsznc>A M2_planet_knight.s wouldn't be a full portable solution for other archs, but it would allow someone who trusts a python on any arch to just audit knight assembler and C and not need to audit x86 assembler and then have useful x86 binaries <oriansj>keep up the good work markjenkinsznc <dddddd>indeed it is oriansj, but I'm not sure what part of the diff is the relevant one. :( Is every change related to it? <oriansj>dddddd: it was the if(EOF == ch) break; the rest was just adding some error catching using require <dddddd>thanks. I get nervous when a commit does more than announced. I have to work on that and let it go a bit (but just a bit, because I think it's important to not mix changes). <oriansj>dddddd: understood and I definitely need to get better about doing it that way myself