On Tue, 2003-02-18 at 09:27, Jonathan Larmour wrote:
I know you've identified the stack checking as the reason, but it's not
really the cause (other than GDB's stack guesswork), so there's still
another interesting issue with this: the stub shouldn't barf. There's
meant to be code to catch this (see cyg_hal_exception_handler() in
hal/powerpc/arch/current/src/hal_misc.c - look at the stuff at the top
about __mem_fault_handler).
If it correctly caught the exception the backtrace would likely work using
GDB's admittedly ramshackle heuristics. *That's* the problem, not the
stack checking itself.
I'll add this to the bug.
I agree that GDB should not barf - certainly that's a problem.
However, I think that the stack checking code is breaking the
EABI and putting stuff on the stack that is, in essence, invalid.
The PowerPC ABIs really suck (thanks, IBM) in that there needs
to be some space (I don't recall how much) *above* the stack
that belongs to the current frame. This means that the last
stack frame (the ending one, hopefully) can't have those
0xDEADBEEF markers immediately adjacent (IIRC).
We should probably look at the ABI and make sure that what we
do with the stack for checking is legal.
Well if there's a problem it's with the HAL. HAL_THREAD_INIT_CONTEXT is
called _after_ all the padding is added, and it's that which should add
any relevant space. For the powerpc, it already leaves
CYGARC_PPC_STACK_FRAME_SIZE which is a whole 56 bytes (which looking at
the eABI I saw, looks like overkill). However I also note that area isn't
initialized to anything. But then we'd see it without the stack frame
checking enabled either.