From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Salter To: john@talisker.demon.co.uk Cc: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] gdb 'next' problem with i386 HAL Date: Wed, 29 Aug 2001 06:47:00 -0000 Message-id: <200108291346.f7TDkrZ06511@deneb.localdomain> References: <01C13098.3C43E7D0@bream.tr.localnet> X-SW-Source: 2001-08/msg00904.html >>>>> 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