Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[android] add hardware specific workaround for Nexus9 in armv7 mode
we got a couple of bug reports, all with the same failure: https://bugzilla.xamarin.com/show_bug.cgi?id=44907 https://bugzilla.xamarin.com/show_bug.cgi?id=46482 https://bugzilla.xamarin.com/show_bug.cgi?id=51791 The bugs are private, therefore here what I wrote: `` Thank you Matthias, this was very helpful. The crash happens on this assignment: https://github.com/mono/mono/blob/de1865dad5c0350f391fedcaa08f02f610530d3f/mono/mini/mini-generic-sharing.c#L418 Here the according disassembly: https://gist.github.com/lewurm/b1094749027c9e5ea19fdc4fac7905a7 The crash happens in the last loop iteration (`r9=i`, `r7=slot`). Looking at the machine code it just _cannot_ happen, which is confirmed by the C code as well: `*oti` successfully happens in the if check, but after returning from `alloc_oti()`, `oti` doesn't contain a valid address anymore. I suspect some weird hardware issue that fails to restore all registers properly from the stack. ``` [...] ``` Thanks again Matthias. Unfortunately, I'm out of ideas, and I can't blame anything but the hardware. The situation we see is too weird. We segfault at offset `0xdda60: str sl, [r4]`, but really we should already segfault at offset `0xdda2c: ldrge sl, [r4, mono#8]!"`. So I suspect two things why this could happen: (1) The instruction at `dda2c` fails to do the post-increment correctly for *whatever* reason. (2) Something along the execution path corrupts the stackslot, where `r4` is saved, in such a way that it *exactly* masks it with `0xf`. Everything else on the stack looks fine, so this is sort of very unlikely to be honest. This only happens on a very specific device: The Nexus 9 is the only device that was ever shipped with the Tegra K1 T132. I suspect an issue in the binary translation layer of `armv7` instruction set to the internal micro-ops of the CPU. I tried to stress test the instruction in question (see https://github.com/lewurm/ldrinsntest), however I was not able to trigger a crash. So either, I'm missing some context in order to trigger the bug or I'm on a completely wrong track. That said, even if we could proof that it is indeed a hardware issue, the workaround is also non-trivial (it would then either need a fix in gcc or require a microcode update by the chip vendor). ``` And then we saw: golang/go#19809 (comment) Another hint that this device is buggy.
- Loading branch information