From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Salter To: jlarmour@redhat.com Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] gdb 'next' problem with i386 HAL Date: Wed, 05 Sep 2001 14:59:00 -0000 Message-id: <200109052159.f85Lxho30700@deneb.localdomain> 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> <3B969616.52A9083A@redhat.com> X-SW-Source: 2001-09/msg00111.html >>>>> Jonathan Larmour writes: > 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. Ok. And all I was saying is that I have a potential fix which doesn't just add 16 to the SP passed to GDB, but rather fixes the SP passed to GDB as part of a larger fix. You said you might try to fix the SP and I wanted to let you know that it may be wasted effort. That's all. --Mark