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

[Mark Salter <msalter@redhat.com>]

>>>>> John Gumb writes:

> Hi,
> I seem to have tracked down the cause of the problem and have a (nasty) workaround but I'm not sure why this is happening in the first place.

> The problem only occurs when 'nexting' over a function call. Immediately on entry to the called function, gdb attempts to work out the return PC address. It does this using the SAVED_PC_AFTER_CALL macro in /src/gdb/insight-5.0/gdb/config/i386/tm-i386.h invoked from step_over_function in /src/gdb/insight-5.0/gdb/infrun.c  What this does is to look on stack for the return address in order that it can set a breakpoint there. SAVED_PC_AFTER_CALL expands to

> read_memory_integer ( read_register (SP_REGNUM), 4) )

> The trouble is, the return address isn't there. I had a poke around and it actually is 16 bytes further down the stack. So I modified the above code to

> read_memory_integer ( read_register (SP_REGNUM)+0x10, 4) )

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.

--Mark