The current context save implementation saves registers of each task
to xcp context, which is unnecessary because most of the arm registers are
already saved in the task stack, this commit replace the xcp context with
stack context to improve context switching performance and reduce the tcb
space occupation of tcb instance.
Signed-off-by: chao.an <anchao@xiaomi.com>
In AArch32, the frame pointer is stored in register R11 for ARM code or register R7 for Thumb code.
In AArch64, the frame pointer is stored in register X29.
Signed-off-by: chao.an <anchao@xiaomi.com>
If we are using the BASEPRI register to disable interrupts, then the answer is that we must disable ONLY the "normal interrupts". That is because we cannot disable SVCALL interrupts and we cannot permit SVCAll interrupts running at a higher priority than the high priority interrupts (otherwise, they will introduce jitter in the high priority interrupt response time.)
Hence, if you need to disable the high priority interrupt, you will have to disable the interrupt either at the peripheral that generates the interrupt or at the NVIC. Disabling global interrupts via the BASEPRI register cannot effect high priority interrupts.
libs/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
syscall/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
wireless/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
Documentation/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
include/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
drivers/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
sched/: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
configs: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
arch/xtensa: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
arch/z80: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
arch/x86: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
arch/renesas and arch/risc-v: Remove references to CONFIG_DISABLE_SIGNALS. Signals can no longer be disabled.
arch/or1k: Remove all references to CONFIG_DISABLE_SIGNALS. Signals are always enabled.
arch/misoc: Remove all references to CONFIG_DISABLE_SIGNALS. Signals are always enabled.
arch/mips: Remove all references to CONFIG_DISABLE_SIGNALS. Signals are always enabled.
arch/avr: Remove all references to CONFIG_DISABLE_SIGNALS. Signals are always enabled.
arch/arm: Remove all references to CONFIG_DISABLE_SIGNALS. Signals are always enabled.
This update is required to be serialized to the instruction stream meaning that after this update completes, it takes effect immediately and no exceptions of lower priority than the new boosted priority can pre-empt execution. Because of this erratum, the priority boosting does not take place immediately, allowing the instruction after the MSR to be interrupted by an exception of lower priority than the new boosted priority. This effect is only limited to the next instruction. Subsequent instructions are guaranteed to see the new boosted priority.
This was raised in Bitbucket issue 113 from Vadzim Dambrouski.
arch/arm: Remove support for CONFIG_ARMV7M_CMNVECTOR. It is now the only vector support available. Also remove CONFIG_HAVE_CMNVECTOR. That no longer signifies anything."
arch/arm/src/stm32: This commit removes support for the dedicated vector handling from the STM32 architecture support. Only common vectors are now supported.
Signal handlers maybe run with interrupts enabled or disabled, depending on how the task the received the signal was blocked. (i.e.: If sem_wait() is called, then we disable interrupts, then block the currently running task). This could be dangerous, because user code would be running with interrupts disabled.
This change forces interrupts to be enabled in up_sigdeliver() before executing the signal handler calling up_irq_enable() explicitly. This is safe because, when we return to normal execution, interrupts will be restored to their previous state when the signal handler returns.
