4 ms·

> While I'm sure [bumping the stack pointer atomically] makes sense, I don't think I've ever seen that be enforced. At least in C/C++. That’s because the C ABI

> While I'm sure [bumping the stack pointer atomically] makes sense, I don't think I've ever seen that be enforced. At least in C/C++. That’s because the C ABI supports unwinding with a fairly expressive set of tools for describing stack-pointer state on a per-instruction level. Even the simpler Microsoft ABI essentially uses bytecode for that[1]; and on the more complicated Itanium ABI, you get DWARF CFI instructions, which make the correct way to preserve a(n x86) register in the function prologue look like push rbx .cfi_adjust_cfa_offset 8 .cfi_rel_offset rbx, 8 which are impossible to miss when reading compiler-generated assembly because of the sheer amount of annoying noise they create. The Go authors decided to sidestep all of this complexity, which is understandable to a degree, but apparently they did not think through all the ramifications of doing so. [1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64 https://learn.microsoft.com/en-us/cpp/build/exception-handli...

dwattttt 1y ago
MS's ARM64 unwinding ABI looks even more complicated: https://learn.microsoft.com/en-us/cpp/build/arm64-exception-handling?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/arm64-exception-...
- mananaysiempre 1y ago
  Ehh I wouldn’t say so (thanks for the correct link for ARM64 though in any case). What you need to be comparing to here is DWARF[1,2] section 6.4, and while it’s not as bad as other parts of DWARF, I still think it’s plenty complicated. [1] https://dwarfstd.org/doc/DWARF5.pdf#page=171 https://dwarfstd.org/doc/DWARF5.pdf#page=171 [2] Slightly modified by psABI[3] section 3.7 for x86-64 or the LSB[4] section 11.6 for ARM64, but at this point that’s a drop in the bucket as far as overall complexity is concerned. [3] https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... [4] https://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic.html#EHFRAMECHPT https://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Core-gene...
  - dwattttt 1y ago
    I was actually looking to point out MS's x64 ABI requires a standardised function epilog since this bug occurred during an epilog, only to find ARM64's epilogues are also described by bytecode (at least at a cursory glance).

dwattttt 1y ago

MS's ARM64 unwinding ABI looks even more complicated: https://learn.microsoft.com/en-us/cpp/build/arm64-exception-handling?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/arm64-exception-...

mananaysiempre 1y ago
Ehh I wouldn’t say so (thanks for the correct link for ARM64 though in any case). What you need to be comparing to here is DWARF[1,2] section 6.4, and while it’s not as bad as other parts of DWARF, I still think it’s plenty complicated. [1] https://dwarfstd.org/doc/DWARF5.pdf#page=171 https://dwarfstd.org/doc/DWARF5.pdf#page=171 [2] Slightly modified by psABI[3] section 3.7 for x86-64 or the LSB[4] section 11.6 for ARM64, but at this point that’s a drop in the bucket as far as overall complexity is concerned. [3] https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... [4] https://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic.html#EHFRAMECHPT https://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Core-gene...
- dwattttt 1y ago
  I was actually looking to point out MS's x64 ABI requires a standardised function epilog since this bug occurred during an epilog, only to find ARM64's epilogues are also described by bytecode (at least at a cursory glance).