0e1b432dd0
reason: svc call may trigger hardfault Background The origin of this issue is our desire to eliminate the function of storing "regs" in g_current_regs and instead utilize (*running_task)->xcp.regs for storage. The benefits of this approach include faster storage speed and avoiding multiple accesses to g_current_regs during context switching, thus ensuring that whether returning from an interrupt or an exception, we consistently use this_task()->xcp.regs Issue Encountered However, when storing registers, we must ensure that (running_task)->xcp.regs is invalid so that it can be safely overwritten. According to the existing logic, the only scenario where (running_task)->xcp.regs is valid is during restore_context. We must accurately identify this scenario. Initially, we used the condition (running_task)==NULL for this purpose, but we deemed this approach unsatisfactory as it did not align well with the actual logic. (running_task) should not be NULL. Consequently, we adopted other arch-specific methods for judgment, but due to special logic in some arch, the judgment was not accurate, leading to this issue. Solution: For armv6-m, we haven't found a more suitable solution, so we are sticking with (*running_task)==NULL. For armv7-m/armv8-m, by removing support for primask, we can achieve accurate judgment. PRIMASK is a design in armv6-m, that's why arm introduce BASEPRI from armv7-m. It's wrong to provide this option for armv7-m/armv8-m arch. Signed-off-by: hujun5 <hujun5@xiaomi.com> |
||
---|---|---|
.. | ||
arm | ||
arm64 | ||
avr | ||
dummy | ||
hc/m9s12 | ||
mips | ||
misoc/lm32/misoc | ||
or1k/mor1kx/or1k | ||
renesas | ||
risc-v | ||
sim/sim/sim | ||
sparc | ||
tricore/tc3xx/tc397 | ||
x86/qemu/qemu-i486 | ||
x86_64/intel64/qemu-intel64 | ||
xtensa | ||
z16/z16f/z16f2800100zcog | ||
z80 | ||
.gitignore | ||
Board.mk | ||
boardctl.c | ||
CMakeLists.txt | ||
dummy.c | ||
Kconfig | ||
Makefile |