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

[Jonathan Larmour <jlarmour@redhat.com>]

Mark Salter wrote:
> 
> >>>>> Jonathan Larmour writes:
> 
> > Mark Salter wrote:
> >>
> >> >>>>> John Gumb writes:
> >>
> >> > The problem only occurs when 'nexting' over a function call.
> > [snip]
> >> > The trouble is, the return address isn't there. I had a poke around and it actually is 16 bytes further down the stack. [snip]
> >>
> >> I think this is a problem in the HAL code. The HAL is passing
> >> the wrong SP value to GDB. The problem is that the HAL stub
> >> uses the same stack as the app being debugged. The HAL should
> >> be switching to a dedicated GDB stub stack.
> 
> > Actually the problem is that on the x86 16 bytes automatically get saved on
> > the stack by the CPU before we have a chance to do anything about it. The
> > solution is to adjust the SP stored by the __default_exception_vsr into the
> > HAL_Saved_Registers struct by 16.
> 
> That still doesn't fix the underlying problem. The stub has to operate on a separate
> stack in order for inferior function calls to work.

Not a problem I was intending to solve here :-).

> GDB will make use of the area
> under the stack to build a call frame. If the HAL stub is using that stack, then
> bad things happen.

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.
 
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