Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Eric Valette]

Sergei Organov wrote:

> Most of BSPs do basically the same thing. If _ISR_Signals_to_thread_executing
> is non-zero, they set it to zero and either call _Thread_Dispatch or return to
> _ISR_Thread_dispatch that in turn calls _Thread_Dispatch. This is the
> documented way to do things. Fine so far. However, there are 3 BSPs that do
> this differently in an undocumented way. Instead of calling _Thread_Dispatch
> directly or indirectly, they call their own _ThreadProcessSignalsFromIrq.
> Maybe it's OK to do it this way, but the question is: why? I guess there
> should be some reason for that. What is the reason?

The reason is that having a context to implement software exception 
(which is what this code does even if not said that way and used in a 
particular way for posix signal) is almost mandatory (e.g to correctly 
implement signals on alternate stack, kernel debuggers, ...). So, when 
implementing exception on those three BSP, I added the push of a context 
similar to the one pushed on real hardware exceptions as this path is 
very unfrequent and anyway performs heavy operation like functions 
calls. The normal path is optimized as usual (or maybe a little bit more 
even).

> If there is one, then why the _ThreadProcessSignalsFromIrq is not in the RTEMS
> core (like _Thread_Dispatch) and why not all the BSPs call it? 

Because the CTX argument is processor dependent and that the actual 
handling of the software exception may also well contain system/board 
specific code.

> Is there an intention to eventually turn all the BSPs to this new calling sequence?

I do not care about that but would like to understand your resistance to 
adopt the new exception handling code (the EABI broken argument can be 
fixed by adding a single ASM instruction to restore R2 before actually 
calling the irq handler). So far you seems to critize something that anyway
	1) you do not use
	2) have not proposed to enhance/fix yet

I think recent discussion on the mailling list made it clear that :
	1) IRQ API should be enhanced and the API proposed on the three BSP you 
mention is already a big step forward,
	2) Exception handling API is also required on many CPU to handle 
recoverable exception, implement debuggers (e.g remote debugging) and 
was indeed missing in PPC, Ix86. NB the remote debugger code could 
actually use software exception to enter the debugger the first time.

-- eric