IRC channel logs

2019-11-01.log

back to list of logs

<oriansj>I finally figured it out!!!
<oriansj>turns out rasm2 was wrong: rasm2 -a x86 -b 64 'xchg rax, rbx' is not 93 but rather 4893
<oriansj>and the fixup.c in M2-Planet was not ever actually needed when that behavior is fixed
<oriansj>also a minor note janneke !foo is only valid in M2-Planet if foo is a boolean (TRUE or FALSE)
<oriansj>if you mean 0 == foo or NULL == foo; it is the M2-Planet way of expressing it as TRUE and FALSE may have alternate meanings than 0 or 1
<oriansj>and with that I present mes-m2; passing the tests without issue
<xentrac>doh
<xentrac>congratulations!
<oriansj>it is such a subtle detail that only showed up in division and I guess I never made the connection
<oriansj>but once I saw rax having -3 and then rbx having 0xFFFFFFFD; I kinda had to stop and think because it seemed too obvious
<xentrac>what kind of testing or verification strategy would have made bugs like that trivial to find?
<oriansj>but there it was and objdump -d confirmed it; the wrong instruction encoding (the only objdump thought included EAX)
<oriansj>probably a good fuzzer or random code generator
<oriansj>basically alot of tests with known answers that forces one to look closer at individual assumptions in the C language.
<oriansj>at the end of the day C compilers don't lend themselves to easy to find bugs; especially in regards to inline assembly or other abuse routes
<xentrac>to use a random code generator you need to have some way to see that the result is wrong
<xentrac>maybe you could assemble the same code with rasm2 and with a different assembler (sed | gas?)
<xentrac>or assemble it with rasm2 and then disassemble it (with objdump or something) to verify round-tripping
<oriansj>well one could use objdump -d to check if the assembled binary has the instruction encoding that rasm2 told you that was the case but there are instructions which both of them get wrong
<oriansj>for example in Intel's own documentation there are 3 different answers for the exact same instruction
<xentrac>yeah
<oriansj>so perhaps designing with the assumption that we will get things wrong and plan in doing approximately the correct thing along the way
<xentrac>I've found Hypothesis to be pretty amazing when I've used it
<xentrac>but I still haven't adopted it for every project
<oriansj>nice
<xentrac> https://blog.trailofbits.com/2019/10/31/destroying-x86_64-instruction-decoders-with-differential-fuzzing/ is potentially relevant
<janneke>oriansj: ah, i did !know what was going on there :)
<janneke>oriansj: this is fantastic news, many congrats!
<janneke>i have been making some nice progress towards a future merge
<janneke>pointer-based plain mes now passes all tests and starts to run with m2-planet
<janneke>there is one last (yeah right, haha!) gc bug that i am struggling with that requires me to use a doubly sized arena for pointer-based cells
***ng0_ is now known as ng0
***edef is now known as edef2
***edef2 is now known as edef
<stikonas>congratulations on passing all tests in mes-m2 :)
<stikonas>I guess there is still some work needed to run mescc.scm
<oriansj>xentrac: thank you looks quite interesting
<oriansj>janneke: well I was planning on replacing your scheme stack with something that should perform better and reduce your memory usage
<oriansj>stikonas: absolutely and a boatload of more tests to be written and bugs before completion but I hope we can be done by Christmas if luck is on our side.