| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Update #3082.
|
| |
|
|
|
|
|
|
|
| |
Implement thread dispatch code in ppc_exc_wrapup() similar to
ppc_exc_interrupt().
Update #2811.
|
|
|
|
|
|
| |
Fix link-time error on BSPs not using PPC_EXC_CONFIG_USE_FIXED_HANDLER.
Update #3085.
|
|
|
|
|
|
|
|
|
| |
Make PPC_EXC_CONFIG_USE_FIXED_HANDLER mandatory for BSPs using
ppc_exc_interrupt(). Pass exception number to bsp_interrupt_dispatch()
to allow processing of decrementer and doorbell exceptions as hypervisor
guest.
Update #3085.
|
|
|
|
|
|
|
| |
In 64-bit mode, the linker must have the ability to restore the TOC
pointer after an external function call.
Update #3082.
|
|
|
|
|
|
|
| |
Rename ppc_exc_wrap_async_normal_end to ppc_exc_interrupt_end to avoid a
bit of obfuscation.
Update #3082.
|
|
|
|
| |
Update #3082.
|
|
|
|
| |
Update #3082.
|
|
|
|
|
|
| |
Use a specific define for the interrupt exception frame size.
Update #3082.
|
|
|
|
|
|
|
| |
Rename ppc_exc_wrap_async_normal to ppc_exc_interrupt to avoid a bit of
obfuscation.
Update #3082.
|
|
|
|
|
|
|
| |
Avoid use of small-data area, since it is not supported in the ELFv2 ABI
by GCC.
Update #3082.
|
| |
|
|
|
|
|
|
| |
There is no need to save the thread pointer in _CPU_Context_switch()
since it is a thread invariant. It is initialized once in
_CPU_Context_Initialize().
|
|
|
|
| |
Closes #3015.
|
| |
|
|
|
|
|
|
| |
Use r8 instead of r5 to slightly optimize _CPU_Context_switch(). It is
not a big deal, however, we already assume r12 is used by
_CPU_Context_switch(). Treat r5 the in same way.
|
| |
|
|
|
|
| |
Update #2751.
|
| |
|
|
|
|
| |
Update #2751.
|
|
|
|
|
|
|
|
|
|
| |
Callers of _Thread_Do_dispatch() must have a valid
Per_CPU_Control::Stats::thread_dispatch_disabled_instant.
Call _Profiling_Outer_most_interrupt_entry_and_exit() with the interrupt
stack to not exceed Per_CPU_Control::Interrupt_frame.
Update #2751.
|
| |
|
|
|
|
| |
Update #2751.
|
|
|
|
|
|
|
|
|
| |
Use a processor-specific interrupt frame during context switches in case
the executing thread is longer executes on the processor and the heir
thread is about to start execution. During this period we must not use
a thread stack for interrupt processing.
Update #2809.
|
|
|
|
|
|
|
| |
Rename ppc_exc_min_frame to CPU_Interrupt_frame. Move it and the
corresponding defines to <rtems/score/cpuimpl.h>.
Update #2809.
|
|
|
|
|
|
| |
We need the unmodified r4 for get_potential_new_heir.
This partially reverts commit 8d785f72d9610fb80a65d7848404f0f7507e026c.
|
|
|
|
|
|
|
| |
Properly pass the stack aligned context to _CPU_Context_switch_altivec()
since _CPU_altivec_ctxt_off defined via ppc_context.
Close #2761.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
According to the C11 and C++11 memory models only a read-modify-write
operation guarantees that we read the last value written in modification
order. Avoid the sequential consistent thread fence and instead use the
inter-processor interrupt to set the thread dispatch necessary
indicator.
|
| |
|
|
|
|
|
|
|
|
| |
Store the floating-point unit property in the thread control block
regardless of the CPU_HARDWARE_FP and CPU_SOFTWARE_FP settings. Make
sure the floating-point unit is only enabled for the corresponding
multilibs. This helps targets which have a volatile only floating point
context like SPARC for example.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add AltiVec and FPU support to the Context_Control in case we use the
e6500 multilib.
Add PPC_MULTILIB_ALTIVEC and PPC_MULTILIB_FPU multilib defines. Add
non-volatile AltiVec and FPU context to Context_Control. Add save/restore of
non-volatile AltiVec and FPU to _CPU_Context_switch(). Add save/restore
of volatile AltiVec and FPU context to the exception code. Adjust data
cache optimizations for the new context and cache line size.
|
|
|
|
| |
This is not correct, but works for now.
|
|
|
|
| |
Provide floating point context support only if PPC_HAS_FPU == 1.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rename _BSP_Exception_frame_print() to _CPU_Exception_frame_print() to
be in line with other CPU port functions.
|
|
|
|
|
|
|
|
| |
Fix context switch on SMP for ARM, PowerPC and SPARC.
Atomically test and set the is executing indicator of the heir context
to ensure that at most one processor uses the heir context. Break the
busy wait loop also due to heir updates.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d9ff8b3e687a0ec56cac6463ba01ba7775eccd41.
It is not that simple:
https://sourceware.org/ml/binutils/2014-06/msg00062.html
On Fri, Jun 06, 2014 at 01:31:48PM +0200, Sebastian Huber wrote:
> On 2014-06-06 13:23, Sebastian Huber wrote:
> >Ok, so this "cmplwi cr0, rX, ppc_exc_lock_std@sdarel" is illegal,
> >since
> >ppc_exc_lock_std@sdarel is signed and the immediate is unsigned
> >16-bit? The
> >assembler doesn't issue a warning about this.
> >
> >Exists there a way to rescue this cmplwi hack without relaxing the
> >overflow
> >checks?
>
> Hm, sorry, it was surprisingly simple. This works:
>
> "cmplwi cr0, rX, ppc_exc_lock_std@sdarel@l"
>
> I was not aware that you can add several @ in a row.
That is the wrong thing to use here. sdarel@l translates to a VLE
reloc which applies to a split 16-bit field in VLE insns.
You want
cmpwi cr0, rX, ppc_exc_lock_std@sdarel
to properly compare a 16-bit signed number from sym@sdarel.
Note that the assembler does error if you write something like
cmplwi 3,-30000
or
cmpwi 3,40000
so what the linker is now doing is extending this behaviour to link
time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See also
https://sourceware.org/ml/binutils/2014-06/msg00059.html
On Fri, Jun 06, 2014 at 11:01:10AM +0200, Sebastian Huber wrote:
> I performed a git bisect and found this:
>
> 93d1b056cb396d6468781fe0e40dd769891bed32 is the first bad commit
> commit 93d1b056cb396d6468781fe0e40dd769891bed32
> Author: Alan Modra <amodra@gmail.com>
> Date: Tue May 20 11:42:42 2014 +0930
>
> Rewrite ppc32 backend .sdata and .sdata2 handling
Hmm, I'm surprised that your git bisect found this patch. Was
_SDA_BASE_ set differently before this?
> 0x00000000000dfc00 _SDA_BASE_
> 0x00000000000d7f78 ppc_exc_lock_std
> 4b8: 28 05 00 00 cmplwi r5,0
> 4ba: R_PPC_SDAREL16 ppc_exc_lock_std
ppc_exc_lock_std@sdarel will be calculating 0xd7f78 - 0xdfc00
which is 0xf...fff8378, and that falls foul of
commit 86c9573369616e7437481b6e5533aef3a435cdcf
Author: Alan Modra <amodra@gmail.com>
Date: Sat Mar 8 13:05:06 2014 +1030
Better overflow checking for powerpc32 relocations
cmplwi has an *unsigned* 16-bit field, and we now check the overflow
properly.
I wonder how many more of these we'll hit, and whether the uproar will
be enough that I'll be forced to relax the checks?
|
|
|
|
|
|
|
|
|
|
| |
We must not alter the is executing indicator in
_CPU_Context_Initialize() since this would cause an invalid state during
a self restart.
The is executing indicator must be valid at creation time since
otherwise _Thread_Kill_zombies() uses an undefined value for not started
threads. This could result in a system life lock.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of task migration in RTEMS has some
implications with respect to the interrupt latency. It is crucial to
preserve the system invariant that a task can execute on at most one
processor in the system at a time. This is accomplished with a boolean
indicator in the task context. The processor architecture specific
low-level task context switch code will mark that a task context is no
longer executing and waits that the heir context stopped execution
before it restores the heir context and resumes execution of the heir
task. So there is one point in time in which a processor is without a
task. This is essential to avoid cyclic dependencies in case multiple
tasks migrate at once. Otherwise some supervising entity is necessary to
prevent life-locks. Such a global supervisor would lead to scalability
problems so this approach is not used. Currently the thread dispatch is
performed with interrupts disabled. So in case the heir task is
currently executing on another processor then this prolongs the time of
disabled interrupts since one processor has to wait for another
processor to make progress.
It is difficult to avoid this issue with the interrupt latency since
interrupts normally store the context of the interrupted task on its
stack. In case a task is marked as not executing we must not use its
task stack to store such an interrupt context. We cannot use the heir
stack before it stopped execution on another processor. So if we enable
interrupts during this transition we have to provide an alternative task
independent stack for this time frame. This issue needs further
investigation.
|
| |
|
| |
|