For 99% of applications, you won't use floats in an interrupt handler, but everyone pays the cost of saving and restoring those registers right now. We should make the save/restore of floats opt-in. I imagine this will make a fair bit of difference to esp-wifi's scheduler performance on Xtensa.

hello-world.elf:     file format elf32-xtensa-le

SYMBOL TABLE:
400c0000 l    d  .rtc.text      00000000 .rtc.text
3ff80000 l    d  .rtc.dummy     00000000 .rtc.dummy
3ff80000 l    d  .rtc.force_fast        00000000 .rtc.force_fast
50000000 l    d  .rtc_noinit    00000000 .rtc_noinit
50000000 l    d  .rtc.force_slow        00000000 .rtc.force_slow
40080000 l    d  .iram0.vectors 00000000 .iram0.vectors
40080400 l    d  .iram0.text    00000000 .iram0.text
3ffb0000 l    d  .dram0.data    00000000 .dram0.data
3ffb1e94 l    d  .noinit        00000000 .noinit
3ffb1e98 l    d  .dram0.bss     00000000 .dram0.bss
3f400020 l    d  .flash.rodata  00000000 .flash.rodata
400d0018 l    d  .flash.text    00000000 .flash.text
00000000 l    d  .debug_frame   00000000 .debug_frame
00000000 l    d  .debug_info    00000000 .debug_info
00000000 l    d  .debug_abbrev  00000000 .debug_abbrev
00000000 l    d  .debug_aranges 00000000 .debug_aranges
00000000 l    d  .debug_ranges  00000000 .debug_ranges
00000000 l    d  .debug_line    00000000 .debug_line
00000000 l    d  .debug_str     00000000 .debug_str
00000000 l    d  .comment       00000000 .comment
00000000 l    d  .xtensa.info   00000000 .xtensa.info
00000000 l    d  .debug_loc     00000000 .debug_loc
00000000 l    df *ABS*  00000000 xtensa_vectors.o

this a snippet from the symbols in a esp32 idf hello world application.

This gives a rough indication of what is required, but the addresses could be wrong as esp-idf projects use a bootloader.

Todo:

• Find documentation on the xtensa vector table setup
• Find documentation on vector section addresses

Issue description
I keep getting Dependabot alerts for GHSA-2qv5-7mw5-j3cg in my project based on esp32-hal v0.16.0. The issue seems to exist in the spin crate for versions below v0.9.8 and using cargo tree I tracked it to this crate which seems to depend on the affected version v0.9.6:

├── esp32-hal v0.16.0
│   ├── embassy-time v0.1.5 (*)
│   └── esp-hal-common v0.13.1
           [..]
│       ├── esp32 v0.27.0
│       │   ├── critical-section v1.1.2
│       │   ├── vcell v0.1.3
│       │   └── xtensa-lx v0.8.0 <---
│       │       ├── bare-metal v1.0.0
│       │       ├── mutex-trait v0.2.0
│       │       └── spin v0.9.6 <---
│       │           └── lock_api v0.4.10
│       │               └── scopeguard v1.1.0
│       │               [build-dependencies]
│       │               └── autocfg v1.1.0

Potential Solution
Bump the dependency of spin to a version that is not vulnerable 🚀

The riscv package provides a default single-hart implementation behind a feature, as seen here.
The cortex-m package does the same here.

Should we move our single-core (and dual-core?) Xtensa implementations into this package in the same manner? While there is no critical need for this change I think trying to keep in line with the other architecture support packages is probably not a bad idea.

The ESP32S2 doesn't support atomics so we should either configure CriticalSectionSpinLockMutex away in that case or emulate it with just a critical section (which would be okay since ESP32S2 is single-core)

The ESP32-S2 and ESP32-S3 are based on the Xtensa LX7 processor. I have opened #12 which adds "support" for this device, however there should probably be some conversation on how we want to handle this moving forwards. Since the Xtensa processors are configurable, there is not necessarily a consistent set of available features.

We're just going to keep forgetting about these packages, so I think it makes sense to move them in along with everything else. This is low-priority, I will take care of it when I get a chance. I'd also like to try and remove the git submodule first.

@MabezDev @bjoernQ please let me know if you have any objections to this, but I think it's the right call.

Are there any plans for supporting the LX2 microarch?

The current critical sections are wrong, see esp-rs/esp-hal#87 for more details, the TLDR is that we should not be disabling interrupts. On top of that, we should probably depend on critical_section crate to get the correct per chip implementations, instead of using interrupt::free everywhere.