From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13699 invoked by alias); 23 Sep 2014 12:27:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13606 invoked by uid 89); 23 Sep 2014 12:27:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,SUBJ_OBFU_PUNCT_MANY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Sep 2014 12:27:21 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XWPBd-0002Zb-Vo from Yao_Qi@mentor.com ; Tue, 23 Sep 2014 05:27:18 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.181.6; Tue, 23 Sep 2014 05:27:17 -0700 From: Yao Qi To: Pedro Alves CC: Jon Burgess , Subject: Re: [RFC][PATCH] arm-tdep.c (arm_m_exception_cache): Handle stack switching to PSP during exception unwind. References: <1411253227.22117.27.camel@shark.nightingale.homedns.org> <8761geykjg.fsf@codesourcery.com> <54213171.1010703@redhat.com> Date: Tue, 23 Sep 2014 12:27:00 -0000 In-Reply-To: <54213171.1010703@redhat.com> (Pedro Alves's message of "Tue, 23 Sep 2014 09:38:09 +0100") Message-ID: <87wq8uwmp1.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00681.txt.bz2 Pedro Alves writes: > Let's start by fixing this properly, please. If GDB needs to know > about these registers, then they should be part of a known feature > in the target description. According to B1.4 in the same document, > we see: > > "The ARMv7-M profile has the following registers closely coupled to the c= ore: > > - general purpose registers R0-R12 > - 2 Stack Pointer registers, SP_main and SP_process (banked versions of R= 13) > - the Link Register, LR (R14) > - the Program Counter, PC > - status registers for flags, exception/interrupt level, and execution st= ate bits > - mask registers associated with managing the prioritization scheme > for exceptions and interrupts > - a control register (CONTROL) to identify the current stack and > thread mode privilege level. > " > > Seems like even more core things other than SP_main/SP_process are > missing from org.gnu.gdb.arm.m-profile, when debugging at this level. > If we add more registers to feature org.gnu.gdb.arm.m-profile, xml files provided by gdb stubs (such as openocd) have to be updated too, otherwise GDB will reject the target description, right? Does this cause any compatibility issue? new gdb rejects the target description from old openocd. >>=20 >>> + gdb_assert (pspreg !=3D -1); >>=20 >> This is too strong to me. If the process sp isn't found, it means GDB >> stub doesn't provide process sp in the target description or the name of >> process sp isn't recognized by GDB. It is not GDB's fault. We can emit >> an error here, IMO. >>=20 >>> + >>> + regcache =3D get_current_regcache (); >>> + pspval =3D regcache_cooked_read_value (regcache, pspreg); >>=20 >> In general, getting the register value in unwinding from current >> regcache is wrong, because register value should be got from the >> previous frame. However, in the case that getting process sp in >> exception on cortex-m, it is correct. At this point, the program is >> still in exception, and main sp is used (process sp isn't used nor chang= ed). >> When GDB is unwinding frames from the exception to the application, the >> process sp register is still valid. > > I suppose this would still break if we have nested exceptions. > For nested exceptions, it returns to handler mode, so the return address (EXC_RETURN) is 0xfffffff1. In this case, EXC_RETURN is 0xfffffffd, it returns to thread mode, so can't be in nested exceptions. > Would it not work to get the register from the frame instead of > the regcache directly? If nothing saves/clobbers it up the frame > chain, the sentinel frame will end up unwinding/reading it from > the current regcache just the same. Agreed. It is better to get register from frame. However, we need to extend standard feature org.gnu.gdb.arm.m-profile first, as you said. --=20 Yao (=E9=BD=90=E5=B0=A7)