This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
gdb 'next' problem with i386 HAL
- To: "'ecos-discuss at sourceware dot cygnus dot com'" <ecos-discuss at sourceware dot cygnus dot com>
- Subject: [ECOS] gdb 'next' problem with i386 HAL
- From: John Gumb <john at talisker dot demon dot co dot uk>
- Date: Wed, 29 Aug 2001 14:38:13 +0100
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)