From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11246 invoked by alias); 23 Sep 2014 08:38:20 -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 11237 invoked by uid 89); 23 Sep 2014 08:38:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 23 Sep 2014 08:38:16 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8N8cC9n016325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Sep 2014 04:38:12 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8N8c9P2003359; Tue, 23 Sep 2014 04:38:10 -0400 Message-ID: <54213171.1010703@redhat.com> Date: Tue, 23 Sep 2014 08:38:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Yao Qi , Jon Burgess CC: gdb-patches@sourceware.org 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> In-Reply-To: <8761geykjg.fsf@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00672.txt.bz2 On 09/23/2014 06:26 AM, Yao Qi wrote: > 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 == 0xfffffffd) { >> + int pspreg; >> + struct regcache *regcache; >> + struct value *pspval; >> + >> + pspreg = 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. 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 core: - general purpose registers R0-R12 - 2 Stack Pointer registers, SP_main and SP_process (banked versions of R13) - the Link Register, LR (R14) - the Program Counter, PC - status registers for flags, exception/interrupt level, and execution state 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. > >> + gdb_assert (pspreg != -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 = get_current_regcache (); >> + pspval = 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. I suppose this would still break if we have 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. Thanks, Pedro Alves