debug: jump to GDB stub upon exception

[lyakh]

Enable a Zephyr option on Xtensa to jump to GDB stub upon exception

[Copilot]

Pull Request Overview

This PR enables GDB stub exception handling for Xtensa architecture by updating the Zephyr revision and adding a debug configuration option.

• Updates Zephyr revision to support Xtensa GDB stub exception handling
• Adds CONFIG_XTENSA_EXCEPTION_ENTER_GDB=y to enable jumping to GDB stub upon exception

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
west.yml	Updates Zephyr revision to newer commit that supports the GDB stub functionality
app/debug_overlay.conf	Adds Xtensa-specific configuration to enable GDB stub exception handling

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[lgirdwood]

@lyakh looks like build errors. Btw, on exception GDB stub should be in read only mode and use a polling based IPC.

[lyakh]

@lyakh looks like build errors. Btw, on exception GDB stub should be in read only mode and use a polling based IPC.

@lgirdwood why IPC? We don't use IPC for the GDB stub, we use a dedicated memory window. As for read-only, well, should be possible in principle, just ignore all the write commands, any specific non-obvious reason for that? Apart from protecting the developer from shooting themselves in the foot?

[lgirdwood]

@lyakh looks like build errors. Btw, on exception GDB stub should be in read only mode and use a polling based IPC.

@lgirdwood why IPC? We don't use IPC for the GDB stub, we use a dedicated memory window. As for read-only, well, should be possible in principle, just ignore all the write commands, any specific non-obvious reason for that? Apart from protecting the developer from shooting themselves in the foot?

If we have a crash then user could write TEXT payload to memory and reboot. We can have a Kconfig for this though as main usage for regular users is to be able to dump data for bug reports.

[lgirdwood]

Gah, clicked wrong button.

[lyakh]

@lyakh looks like build errors. Btw, on exception GDB stub should be in read only mode and use a polling based IPC.

@lgirdwood why IPC? We don't use IPC for the GDB stub, we use a dedicated memory window. As for read-only, well, should be possible in principle, just ignore all the write commands, any specific non-obvious reason for that? Apart from protecting the developer from shooting themselves in the foot?

If we have a crash then user could write TEXT payload to memory and reboot. We can have a Kconfig for this though as main usage for regular users is to be able to dump data for bug reports.

@lgirdwood but they can do that with no crash too. Just use the GDB stub as always, no crash is needed, or what am I missing?

[lgirdwood]

@lyakh looks like build errors. Btw, on exception GDB stub should be in read only mode and use a polling based IPC.

@lgirdwood why IPC? We don't use IPC for the GDB stub, we use a dedicated memory window. As for read-only, well, should be possible in principle, just ignore all the write commands, any specific non-obvious reason for that? Apart from protecting the developer from shooting themselves in the foot?

If we have a crash then user could write TEXT payload to memory and reboot. We can have a Kconfig for this though as main usage for regular users is to be able to dump data for bug reports.

@lgirdwood but they can do that with no crash too. Just use the GDB stub as always, no crash is needed, or what am I missing?

RW Stub would be built in by developers for dev usage today, but RO crash stub would be in production build for end users to help report issues.

[lyakh]

RW Stub would be built in by developers for dev usage today, but RO crash stub would be in production build for end users to help report issues.

@lgirdwood ah, I see now! Thanks for the clarification. That needs a bit more work then, we need at least two Kconfig options then, so far we have only one.