From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-25520-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 5735 invoked by alias); 8 Jun 2006 12:25:44 -0000
Received: (qmail 5715 invoked by uid 22791); 8 Jun 2006 12:25:42 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.s.netic.de (HELO mail.s.netic.de) (212.9.160.11)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Jun 2006 12:25:39 +0000
Received: from host-213-178-187-8.dsl.netic.de ([213.178.187.8] helo=schleim.qwe.de) 	by mail.s.netic.de with esmtp (Exim 4.51) 	id 1FoJZv-000Iw3-Gr; Thu, 08 Jun 2006 14:25:35 +0200
Received: from localhost (localhost [IPv6:::1]) 	by schleim.qwe.de (Postfix) with ESMTP id 0A6CF3B45C; 	Thu,  8 Jun 2006 14:29:21 +0200 (CEST)
From: Torsten Mohr <tmohr@s.netic.de>
To: gdb@sourceware.org
Subject: Re: V850E simulator, assembler single-step never returns?!?
Date: Thu, 08 Jun 2006 21:37:00 -0000
User-Agent: KMail/1.8
Cc: Daniel Jacobowitz <drow@false.org>,  Keith Seitz <keiths@redhat.com>
References: <200606052145.25672.tmohr@s.netic.de> <200606080053.58952.tmohr@s.netic.de> <20060607232402.GA26181@nevyn.them.org>
In-Reply-To: <20060607232402.GA26181@nevyn.them.org>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200606081429.20599.tmohr@s.netic.de>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-06/txt/msg00058.txt.bz2

Hi,

> No.  You need to run it inside another debugger session using a native
> GDB.

Ok, i recompiled v850-unknown-elf-insight with CFLAGS=-g set.

When i now start this one in a normal PCs insight and provoke the
error i observe the following:

The stack trace shows quite many functions at startup and then we go
to a loop:
...
...
catch_errors
wrapped_call
gdb_stack
GDB_get_prev_frame
call_wrapped_function
catch_errors
wrap_get_prev_frame
get_prev_frame
get_prev_frame_1
get_frame_id
v850_frame_this_id
v850_frame_cache
frame_unwind_register_unsigned
frame_unwind_register
frame_register_unwind
v850_frame_prev_register
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
... goes on quite long and does not seem to stop ...


Is this of any help for anybody?  How should it look like?


Is it possible that this behaviour is provoked by bad memory
layout in the target (the debugged program in the simulator)?


Best regards,
Torsten.