LLVM code generation bug. Imagine loading gdb and reproducing the crash, only to see a stack trace where every frame is `????????` and raw assembly (because the

LLVM code generation bug. Imagine loading gdb and reproducing the crash, only to see a stack trace where every frame is `????????` and raw assembly (because the upper half is generated code and the lower half is corrupted). Then you finally determine a global variable (field in a struct pointer) is responsible for the crash, run rr and find a C function which modifies said variable…except it’s modifying a completely unrelated local variable (like, of a different pointer type) which happens to have the same address as this field. Also, it’s hard to find a minimal example, and the range of code where the bug could be is very large. Perhaps LLVM is compiling an allocation which somehow allocated memory in the same place as the global’s allocation? or perhaps somehow the global is getting assigned to the variable (though it seems trivially not, maybe LLVM is compiling arguments wrong)? I don’t actually know, I haven’t fixed the bug but it’s not currently an issue. How do you even fix something like that? I’d probably insert logs in the generated code to minimize the location where the bug could be found. But I have no idea how the local variable gets the same address as the global’s field…