[ECOS] gdb 'next' problem with i386 HAL
Mark Salter
msalter@redhat.com
Wed Sep 5 08:44:00 GMT 2001
>>>>> 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. 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.
I've got a set of half-baked patches to fix GDB testsuite failures on i386. I'm
hoping to get them cleaned up and checked in this week.
--Mark
More information about the Ecos-discuss
mailing list