1. 9

    1. 2

      Was this in Go or in Purego, and does that make a difference?

      1. 2

        The main difference is how much of a risk it is to third parties: if it’s an issue in Go, then others will almost certainly fall victim to it, and raising awareness would be helpful.

        I’m not sure how to classify it though: on the one hand, Go’s assembly is a semi-abstract instruction set designed to support the compiler toolchain, so there is no guarantee whatsoever the final machine code will match the source assembly, and even less guarantee that it will respect platform calling conventions. And indeed neither is true.

        On the other hand, Go has its own assembly and this has first-class support in the toolchain.

      2. 1

        The way I read this, it is a bug in Purego due to some element of the pseudo-assembly they are writing. It seems that they were violating some element of the arm64 calling convention if I’m reading it properly. It would be nice if go had a way to check this, but the goal of the golang tooling is more to support people writing go, than people writing go’s pseudo-assembly. IMHO, the title is rather misleading.