From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18808 invoked by alias); 23 Sep 2014 05:30:58 -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 18778 invoked by uid 89); 23 Sep 2014 05:30:54 -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 05:30:52 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1XWIgb-0003CY-FN from Yao_Qi@mentor.com ; Mon, 22 Sep 2014 22:30:49 -0700 Received: from GreenOnly (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.181.6; Mon, 22 Sep 2014 22:30:48 -0700 From: Yao Qi To: Jon Burgess CC: 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> Date: Tue, 23 Sep 2014 05:30:00 -0000 In-Reply-To: <1411253227.22117.27.camel@shark.nightingale.homedns.org> (Jon Burgess's message of "Sat, 20 Sep 2014 23:47:07 +0100") Message-ID: <8761geykjg.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/msg00670.txt.bz2 Jon Burgess writes: > + /* The EXC_RETURN address indicates what type of transition Nitpick: I'd like to say "EXC_RETURN (exception return address)" rather than "EXC_RETURN address", because its value is the magic address. > + the CPU makes when returning from the exception. A value > + of 0xfffffffd causes the stack pointer to switch from > + MSP to PSP. */ I'd like to replace MSP and PSP with SP_main and SP_process, which are used in the ARMv7-M ARM. These details in your comments are described in ARMv7-M ARM. IWBN to add something like: See details in "B1.5.8 Exception return behavior" in "ARMv7-M Architecture Reference Manual". > + if (this_pc =3D=3D 0xfffffffd) { > + int pspreg; > + struct regcache *regcache; > + struct value *pspval; > + > + pspreg =3D user_reg_map_name_to_regnum (gdbarch, "psp", 3); The main sp and process sp aren't in the gdb's target description. Different gdb stubs (jtag probes) may name them differently. OpenOCD names it as "psp", but our codesourcery sprite names it as "sp_main". We may need an array for the names of process sp, and iterate the array to find the number by different name variants. > + gdb_assert (pspreg !=3D -1); 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. > + > + regcache =3D get_current_regcache (); > + pspval =3D regcache_cooked_read_value (regcache, pspreg); 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 changed). When GDB is unwinding frames from the exception to the application, the process sp register is still valid. --=20 Yao (=E9=BD=90=E5=B0=A7)