From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Mark Salter Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] gdb 'next' problem with i386 HAL Date: Wed, 05 Sep 2001 14:16:00 -0000 Message-id: <3B969616.52A9083A@redhat.com> References: <01C13098.3C43E7D0@bream.tr.localnet> <200108291346.f7TDkrZ06511@deneb.localdomain> <3B964586.739C5116@redhat.com> <200109051544.f85FiKl19204@deneb.localdomain> <3B964AE0.10557995@redhat.com> <200109051633.f85GXuN30119@deneb.localdomain> X-SW-Source: 2001-09/msg00110.html 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