From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Gumb To: "'ecos-discuss@sourceware.cygnus.com'" Subject: [ECOS] gdb 'next' problem with i386 HAL Date: Wed, 29 Aug 2001 06:42:00 -0000 Message-id: <01C13098.3C43E7D0@bream.tr.localnet> X-SW-Source: 2001-08/msg00903.html 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) ) and I appear to have correct 'next' behaviour. I'd need to do a *lot* more testing to be sure this is working properly though. I'd be most grateful if anyone could shed light on what's actually going on. I'm guessing that another stack frame has been pushed on somehow. FYI we can actually see this going wrong in the trace I posted: Sending packet: $m11575c,4#33...Ack Packet received: 01000000 Sending packet: $g#67...Ack Packet received: 2083110004000000e0821100040000005c57110088571100207f01006caa110 0a4dd100007000000080000000000000000000000 Sending packet: $m1,1#fb...Ack Packet received: e7 Sending packet: $X1,1:Ì#ec...Ack The $m11575c,4 is attempting to get the return PC. The target responds with 0x00000001. After getting the registers GDB then attempts to set a break at address1 (Sending packet: $X1,1:Ì#ec...Ack). This will not be of much use. You can imagine it was a blast debugging this :-) Cheers, John Gumb Ridgeway Systems and Software john@gumb.org (home) jgumb@ridgeway-sys.com (work)