This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: gdb 'next' problem with i386 HAL
- To: jlarmour at redhat dot com
- Subject: Re: [ECOS] gdb 'next' problem with i386 HAL
- From: Mark Salter <msalter at redhat dot com>
- Date: Wed, 5 Sep 2001 11:44:20 -0400
- CC: john at talisker dot demon dot co dot uk, ecos-discuss at sourceware dot cygnus dot com
- References: <01C13098.3C43E7D0@bream.tr.localnet> <200108291346.f7TDkrZ06511@deneb.localdomain> <3B964586.739C5116@redhat.com>
>>>>> 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