arch: _callee_saved_t → struct arch_csf & pass csf to fatal handling APIs

[ycsin]

• Deprecate _callee_saved_t
• Rename struct _callee_saved to struct arch_csf, and add it to the arch_interface.h

The goal is to pass arch-agnostic callee-saved-registers to k_sys_fatal_error_handler & z_fatal_error, so that the error handlers can do more.

This is somewhat similar to #73593

[andyross]

Would maybe a cleaner way to do this be to move all the register block info out of the core kernel interface entirely? Then each arch can define its own arch-specific region of the stack frame struct (potentially even as a pointer to the context save data in the thread struct, avoiding some copies we currently have to do), and get the core kernel out of the business of trying to define what lives there?

Basically not loving the extra argument to z_fatal_error() -- that API should be getting less complicated, not more, IMHO.

[npitre]

I have a nagging impression that this is just too much churn.

Why not simply adding a field in the esf structure for a csf pointer instead?

Those architectures who care can do it, those who don't may ignore it, and
the core code remains oblivious to such particularities. Otherwise, an extra
argument does add some small overhead to everyone even when unused.

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
sof	zephyrproject-rtos/sof@0e4c4ef (zephyr)	zephyrproject-rtos/sof#49	zephyrproject-rtos/sof#49/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[ycsin]

Why not simply adding a field in the esf structure for a csf pointer instead?

I did something similar internally by (ab)using the CONFIG_RISCV_SOC_CONTEXT_SAVE, could you take a look at #78065?

[ycsin]

Then each arch can define its own arch-specific region of the stack frame struct (potentially even as a pointer to the context save data in the thread struct, avoiding some copies we currently have to do), and get the core kernel out of the business of trying to define what lives there?

Sorry, I don't quite get this, could you elaborate this a little more, maybe with an arch as an example?

[andyross]

I have a nagging impression that this is just too much churn.

True enough, though to be honest some churn here wouldn't be a bad thing. The "callee_saved" region is a weird mess, and very old. A clean abstraction for "how to pass arch-dependent exception data to the app fatal error handler" would definitely be a good thing.

[ycsin]

Is the rename of _callee_saved_t → struct arch_csf in this PR something that we would want?