Re: [ECOS] gdb 'next' problem with i386 HAL

[Jonathan Larmour <jlarmour@redhat.com>]

Mark Salter wrote:
> 
> >>>>> Jonathan Larmour writes:
> 
> > So you've presumably added something to switch to the interrupt stack. Fair
> > enough, but isn't that a separate issue? The SP value stored in the
> > HAL_SavedRegisters is still off by 16 no matter what stack you're running
> > on. The SP value to report to GDB must still be the value at the time of
> > the exception, not the value just after it, no matter what.
> 
> I pop those values off the application stack before copying them to the
> stub stack frame. The correct SP just comes out of that. I'm not sure
> that simply adjusting the SP is sufficient. It may be for 'next' but
> inferior function calls may corrupt the area under the SP passed to
> GDB.

I'm not saying it's _sufficient_ for inferior function calls to work. I'm
saying it is necessary in all situations i.e. even ignoring inferior
function calls.

The correct SP simply cannot come out of any value on the stack. If you are
getting the correct SP, then I don't know how. When __default_exception_vsr
is called, SP will already be 16 bytes further down before the VSR handler
has had a chance to do the pusha - because the CPU has saved stuff on the
stack and the trampoline has saved the vector number, adding up to 16
bytes. You have to re-adjust it manually within the Hal_SavedRegisters
structure. I would imagine it's only after that point that (subject to
HAL_USE_INTERRUPT_STACK configury) you'll be able to switch stacks and do
anything to pop values off the application stack.

NB if you're playing in this area, be aware of any ramifications of
hal_fpu_push_int_annex when doing lazy FPU switching. You may not be using
that code in the configuration you are using.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine