From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3310 invoked by alias); 24 Nov 2003 14:16:17 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 3302 invoked from network); 24 Nov 2003 14:16:16 -0000 Received: from unknown (HELO msgdirector3.onetel.net.uk) (212.67.96.159) by sources.redhat.com with SMTP; 24 Nov 2003 14:16:16 -0000 Received: from miso.calivar.com (213-78-70-36.friaco.onetel.net.uk [213.78.70.36]) by msgdirector3.onetel.net.uk (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id BJW63147; Mon, 24 Nov 2003 14:16:08 GMT Received: from miso.calivar.com (miso.calivar.com [127.0.0.2]) by miso.calivar.com (Postfix) with ESMTP id 2BBCD28DF45; Mon, 24 Nov 2003 14:16:07 +0000 (GMT) To: "Dirk Broer" Cc: "ECOS" References: From: Nick Garnett Date: Mon, 24 Nov 2003 14:16:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [ECOS] Unexpected exception handler call (0x53) X-SW-Source: 2003-11/txt/msg00326.txt.bz2 "Dirk Broer" writes: > We are newly targeting an arm based board. >=20 > We get often an exception with 0x53 (83). Do you really mean exception 0x53? The ARM only has four possible exceptions, numbered 1-4. Do you actually mean an interrupt? Alternatively, maybe the stack is being corrupted and the exception value is bogus. >=20 > Back Trace shows nothing interesting. What does backtrace actually show? >=20 > How best to proceed to track this down? Where would the =C2=91real=C2=92= stack have > been stored? Was it stored? Exceptions are usually handled on the stack that was current when the exception occurred. In GDB the value of r13 will be the SP of the interrupted code. If this is a real exception then looking at what the insruction pointed to by the PC was doing should give you a clue. >=20 > My best guess is that this is the default handler, should we override thi= s? > Again, can we recover the stack? You should not need to do anything special here. The default VSR should dump you into the GDB stubs, which is what you want. >=20 > We are still implementing =C2=91info threads=C2=92 and right now have no = direct > visibility on the state of other threads in the system. > Why do you need to implement the "info threads" stuff? This is all handled by target-independent code, HAL ports should not need to do anything about this. --=20 Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss