views:

304

answers:

3

I'm writing an assembler routine to handle the 0x500 external/decrementer exception in an EABI embedded PowerPC application.

In my assembler routine called from the 0x500 vector point I want to use some memory to context save registers before branching to the handler function in 'C'.

Because i) the exception model guarantees the previous instructions will have finished by the time the exception handler runs AND ii) the calling convention appears to update the stack pointer (r1) first on entering a new function, before using the new stack space freed up by moving it (and move the stack pointer back to where it was last at the end of the function)

it appears to me that I can safely use r1 to give myself some more space on the normal stack in the exception processing routines, provided obviously I adhere to the calling convention and put the stack back how I found it and make sure SRR0 and SRR1 are unmodified.

I'm not going to allow exceptions that use the stack in their handling to nest (although actually using this method I'm not sure there would be a problem).

Do you think this is a wise approach, or should I use a separate stack for exception handling? - I'm thinking this may bring with it its own problems.

+1  A: 

The only downside I can see to saving register context on the stack is that one of the exceptions you may run into is a stack overflow!

Crashworks
:-) fortunately I have about 98% of my RAM free for the stack. It's a much simpler program than the board was designed to run
sparklewhiskers
+3  A: 

Embedded systems do this both ways. If you are completely confident that the stack pointer will always point to a valid frame and there will room in the stack for your new frame, then go ahead and use it. If there's a chance that the stack pointer will not always be valid, you should save the old stack pointer (typically in an SPRG) and set up your own.

If you're going to handle data access exceptions to detect software errors, you'll certainly want to set up your own exception stack because the DACC may have been caused by a broken stack pointer.

+1  A: 

I have saved the current context to the current stack with out any problems.

You need to differentiate between exceptions from which you would want to return from and exceptions that are "Fatal Failures" from which there is no return or that stack can not be trusted. If you are not going to return you have two options. Restart the stack and discard everything or if you have more RAM switch to an exception stack so the regular stack can be printed or ...

Gerhard
yes, I copy what you say about different types of exceptions. The only exception I'm planning on handling using this method is an external exception, which in my case is a 'good' exception
sparklewhiskers