headers
peter garrone | 4 Feb 2005 04:10

Fw: Re: stepping problem with sh4, gdbserver

----- Original Message -----
From: "peter garrone" <pgarrone <at> linuxmail.org>
To: gdb <at> gnu.org
Subject: Re: stepping problem with sh4, gdbserver
Date: Thu, 03 Feb 2005 13:27:53 +0800

I think these problems are due to a config mixup, it is being set up as an sh rather than sh4.

--

-- 
______________________________________________
Check out the latest SMS services  <at>  http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze
Permalink | Reply | 0 comments |
headers
peter garrone | 2 Feb 2005 07:51

stepping problem with sh4, gdbserver

Hi,
 While debugging remotely with gdbserver and stepping the gdb (6.3) test program "break.c" at line 96, the
"next" command causes a segfault at frame.c line 1244 (frame->next != NULL) because frame is null. The
relevant backtrace is:

get_frame_pc(frame = 0)  frame.c:1244
insert_step_resume_breakpoint_at_frame(return_frame=0) infrun.c:2670
handle_inferior_event infrun.c:2449
wait_for_inferior infrun.c:991

Tracing the execution of gdb itself, handle_inferior_event is invoked one instruction before and then at
the point of calling the function marker1, according to the value of stop_pc at infrun.c:1547. This
second invocation of handle_inferior_event inserts a breakpoint at the return point (stop_pc + 4) and
returns. Then handle_inferior_event is invoked again, this time stop_pc is set to the address of the very
first instruction of the marker1 function. The test at infrun.c:2285 if(frame_id_eq(.....)) returns
true and the block following  is taken.
Execution proceeds to line 2449
"insert_step_resume_breakpoint_at_frame(get_prev_frame(get_current_frame())" where the error occurs.

I dont understand why gdb would set a breakpoint in marker1 when it is stepping over the function. At the
first instruction of marker1, the stack would still be unchanged from its value in the top function, since
the sh4 does not change the stack when it calls a subroutine, so perhaps this has something to do with it.

I am using gdb 6.3, but have seen a similar error on previous versions. Configuration is for
sh4-xxx-linux-gnu, gdb_target=linux, --enable-shared, --enable-threads
The only relevant source change is an include in gdbserver/linux-sh-low.c where #include <sys/reg.h> is
commented out.

Any help appreciated.
Peter Garrone
(Continue reading)

Permalink | Reply | 0 comments |
headers
peter garrone | 3 Feb 2005 06:27

Re: stepping problem with sh4, gdbserver


I made some errors due to fact the copy of gdb was optimised. apologies. 
The break PC for the prior run of handle_inferior_event was assumed to be the current runs value.

> 
> Hi,
>   While debugging remotely with gdbserver and stepping the gdb 
> (6.3) test program "break.c" at line 96, the "next" command causes 
> a segfault at frame.c line 1244 (frame->next != NULL) because frame 
> is null. The relevant backtrace is:
> 
> get_frame_pc(frame = 0)  frame.c:1244
> insert_step_resume_breakpoint_at_frame(return_frame=0) infrun.c:2670
> handle_inferior_event infrun.c:2449
> wait_for_inferior infrun.c:991
> 
> Tracing the execution of gdb itself, handle_inferior_event is 
> invoked 
when the target hits a break at the subroutine, whereopon gdb sets a break at the subroutine return point.
When it hits this return point break, it appears to erroneously pass the frame_id_eq test at infrun.c:2285
The data passed to frame_id_eq is identical to the previous invocation when gdb was servicing the break
within the subroutine.
According to the block comment, it is only entered when a subroutine is debugged, so I assume this is an error.

So gdb appears to be mistakenly assuming that it is in a subroutine when in fact it has returned.

 
> I am using gdb 6.3, but have seen a similar error on previous 
> versions. Configuration is for sh4-xxx-linux-gnu, gdb_target=linux, 
> --enable-shared, --enable-threads
(Continue reading)

Permalink | Reply | 0 comments |

Gmane