That's not what "confirmed bug" means. Confirmed means the reason is clear and it can be explained why particular place crashes.
I am 100% sure this is not a bug in mesa, but bug in your code. Disassembly clearly shows that.
First of all - have you tried running code without any hacks? libc replacements/_start/syscalls? Because bug can be in one of those - it messes up something that compiler does not expect (for example, stack alignment), and thus you see crash later. And it was not happening before because you were lucky, the compiler produced code that did not trigger the bug.
Crash doesn't crash "without reason". There is a reason. The instruction you highlighted can crash if %rcx register contains invalid address. Check the address in debugger and why it is wrong.
I could not compile your code on my ArchLinux:
1) I needed to add "-fno-stack-protector" to compiler arguments in
build_main.sh. Otherwise it failed with missing __stack_chk_fail symbol.
2) I needed to change clang to gcc in
build_lib0.sh. Clang takes forever to compile, not sure if it finishes at all. Waited like for 1 minute. gcc finishes instantly.
3) I needed to change order of scripts in
build.sh -
build_texteditor.sh should come before
build_lib0.sh
After I could run ./main. Application launched. No crashes (on ArchLinux with mesa 17.2.6). But I don't see anything in window. Its completely empty and not refreshing.
Btw your stdlib_gettimeofday implementation is super inefficient. Real gettimeofday implementation doesn't do syscalls (which are very slow). It simply reads shared memory region which is super fast operation:
https://blog.packagecloud.io/eng/...ystem-calls/#virtual-system-calls