Skip to content

Conversation

alexrp
Copy link
Member

@alexrp alexrp commented Oct 7, 2025

No description provided.

@alexrp alexrp force-pushed the std-debug-mips-ppc branch 3 times, most recently from 427bd0b to 0f37b9e Compare October 7, 2025 07:28
@mlugg
Copy link
Member

mlugg commented Oct 7, 2025

Hm, I was trying to avoid making the arch-specific declarations in std.debug.cpu_context depend on the native architecture. I didn't have a concrete use case in mind, but I figured it certainly couldn't hurt to expose cpu_context.X86_64; digging for a use case, maybe you have some system which can't print stack traces itself, but can send a CPU context over the wire to some other system which can then use that to print stack traces or something? Not sure.

Regardless: I think either the declarations should not depend on the native architecture (so split into Mips32 and Mips64, or maybe Mips(32) and Mips(64) to share code), or they should not be marked pub so that this interface explicitly only supports the native target. Right now it's in a bit of an awkward middle ground IMO.

@alexrp
Copy link
Member Author

alexrp commented Oct 7, 2025

Hm, I was trying to avoid making the arch-specific declarations in std.debug.cpu_context depend on the native architecture. I didn't have a concrete use case in mind, but I figured it certainly couldn't hurt to expose cpu_context.X86_64; digging for a use case, maybe you have some system which can't print stack traces itself, but can send a CPU context over the wire to some other system which can then use that to print stack traces or something? Not sure.

The only things that come to mind are:

  • A remote debugger: This obviously has much more advanced needs that std.debug does not at all cater to, and probably never will.
  • A watchdog process: This collects a stack trace from a child process on crash (and probably restarts it). This I could see potentially being served by std.debug in the future.

Regardless: I think either the declarations should not depend on the native architecture (so split into Mips32 and Mips64, or maybe Mips(32) and Mips(64) to share code), or they should not be marked pub so that this interface explicitly only supports the native target. Right now it's in a bit of an awkward middle ground IMO.

I find the value of them being public a bit dubious; I just copied that from the existing ones. I don't think the public declarations are all that useful for the remote stack trace use case anyway, so probably making them private is reasonable?

alexrp added 14 commits October 7, 2025 16:47
…race

Fixes stack traces missing a frame depending on inlining decisions.

ref ziglang#25418
…t bitness

We care about the hardware here, not the ABI.
32-63 conflict with the floating point registers.
32-63 conflict with the floating point registers. 64 is the Alternate Frame
Return Column.
It's free real estate, as it turns out.
32-63 conflict with the floating point registers. 64 and 65 are used for the
ac0 hi/lo registers.
Let's for the moment assume that compilers haven't lost the plot.

Fingers crossed.
@alexrp alexrp force-pushed the std-debug-mips-ppc branch from 0f37b9e to e4f0c62 Compare October 7, 2025 15:11
@alexrp alexrp requested review from mlugg and removed request for mlugg October 7, 2025 19:26
@alexrp alexrp enabled auto-merge October 7, 2025 23:11
@alexrp alexrp merged commit 2aea7a4 into ziglang:master Oct 8, 2025
9 checks passed
@alexrp alexrp deleted the std-debug-mips-ppc branch October 8, 2025 05:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants