authorgravatar for mlugg@mlugg.co.ukMatthew Lugg <mlugg@mlugg.co.uk> 2025-09-20 15:16:42+01:00
committergravatar for mlugg@mlugg.co.ukMatthew Lugg <mlugg@mlugg.co.uk> 2025-09-30 13:44:56+01:00
logf7e0ff8a5fb3e8426e8f64bba271eae358d123b4
tree32056a86cbcf95e4c64750ddb704c0b7d6390ddb
parentb0f222777c38088d90041ba1f28bfb1341cc76c6
signaturelock-open Commit is signed but in an unrecognized format.

std: clarify cpu_context register order rationale

1 files changed, 6 insertions(+), 3 deletions(-)

lib/std/debug/cpu_context.zig+6-3
......@@ -225,8 +225,9 @@ pub fn fromWindowsContext(ctx: *const std.os.windows.CONTEXT) Native {
225225}
226226
227227pub const X86 = struct {
228 /// The first 8 registers here intentionally match the order of registers pushed
229 /// by PUSHA, which is also the order used by the DWARF register mappings.
228 /// The first 8 registers here intentionally match the order of registers in the x86 instruction
229 /// encoding. This order is inherited by the PUSHA instruction and the DWARF register mappings,
230 /// among other things.
230231 pub const Gpr = enum {
231232 // zig fmt: off
232233 eax, ecx, edx, ebx,
......@@ -283,7 +284,9 @@ pub const X86 = struct {
283284};
284285
285286pub const X86_64 = struct {
286 /// MLUGG TODO: explain this order. why does DWARF have this?
287 /// The order here intentionally matches the order of the DWARF register mappings. It's unclear
288 /// where those mappings actually originated from---the ordering of the first 4 registers seems
289 /// quite unusual---but it is currently convenient for us to match DWARF.
287290 pub const Gpr = enum {
288291 // zig fmt: off
289292 rax, rdx, rcx, rbx,