From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26561 invoked by alias); 15 Dec 2015 00:13:19 -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 26551 invoked by uid 89); 15 Dec 2015 00:13:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no 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, 15 Dec 2015 00:13:17 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3CD618E25B; Tue, 15 Dec 2015 00:13:16 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBF0DFNk014171; Mon, 14 Dec 2015 19:13:15 -0500 Message-ID: <566F5B1A.8040703@redhat.com> Date: Tue, 15 Dec 2015 00:13:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christopher Friedt CC: gdb-patches@sourceware.org Subject: Re: cortex-m xml register descriptions for m-system References: <566F108D.1000401@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00273.txt.bz2 On 12/14/2015 11:11 PM, Christopher Friedt wrote: > On Dec 14, 2015 1:55 PM, "Pedro Alves" wrote: >> >> Does GDB need to be aware of these registers at all? That is, does gdb >> need to be aware of org.gnu.gdb.arm.m-system? Usually GDB needs to >> be aware of specific registers if for instance Dwarf can refer to them. >> Otherwise, the design of xml descriptions is such that you're free >> to send any additional registers you want without a specific feature. >> GDB will show them. > > Hmm... It's hard for me to say. The MSP and PSP are banked stack > pointers, control instructs the core which stack pointer to use, and > they are also tightly coupled to exception entry, so I would lean > towards yes? If you can think of some gdb feature that would need hard coding the awareness of the existence of these registers, then that's an indication you'd want to create a new standard target feature to wrap the registers, so gdb could check whether the feature is present on the target gdb just connected to. Then gdb's ARM backend code (gdb/arm-tdep.c) would check whether the feature is listed as present in the target description the stub sent, and if it is present, validate that the corresponding set of register registers is included in the reported description, like is done already for other standard features: https://sourceware.org/gdb/onlinedocs/gdb/Standard-Target-Features.html TBC, the stub is free to send other unknown registers in the target description. That is, if you adjust your stub to send a description like this: It'll work just as well. GDB will display the registers just fine. IOW, if you're not sure, it probably means no, you don't need the new feature. (BTW, features put under the "org.gnu.gdb" namespace must all be documented in the gdb's manual.) That said, if multiple projects want it, I guess it wouldn't hurt to put an official xml file in the gdb tree, just so everyone has a canonical place to copy the file from. >>> The first question I would ask for clarification from the binutils-gdb >>> developers, is, which regnum is appropriate to assign to each of those >>> m-system registers? Should these registers enumerate starting with 26 >>> (resuming from the xpsr)? >> >> I don't think the regnums matter. GDB should be adjusting itself >> dynamically. >> >> The regnums only matter for backward compatibility with stubs that >> don't report XML descriptions. In that case, GDB will fallback to >> internal XML descriptions guessed from e.g., the binary loaded, and >> in that case the expected offsets in the g/G packets must match what >> the stub actually sends. > > Exactly, I just want to ensure that the numbering *is* backward > compatible with stubs that don't support XML descriptions. Can you clarify? What stubs would those be? Since GDB has no built-in knowledge of these registers, when debugging against stubs that don't sent a target description, there's no way they would ever be presented. > I believe > anything beyond 26 should be fine, as it does not interfere with core > registers, the PSR, or FPA registers. Is that a correct assumption? > >> Even though all Cortex-M CPUs have these registers, userspace >> debuggers/servers can't access them, right? > > With the chips I have worked with, I definitely could access (i.e. > write to) the msp, psp, primask, faultmask, basepri, and control > registers, via OpenOCD. I think the only non-addressible register that > can't be written is the xpsr, iirc (which is not part of m-system). I meant things like Linux/ptrace, where a non-privileged userspace debugger normally can't access system/privileged registers. Even though m-profile targets the microcontroller space, there's a Linux port that runs on it, for example. So getting back to the original question: > 1) Should it be inserted directly into arm-m-profile.xml? > 2) Should it be included from arm-m-profile.xml as arm-m-system.xml? If you asking about gdb's copy of the files, the answer is neither. Leave those alone for stubs that don't have access to the system registers. We'd instead need a new file arm-m-system.xml that lists the system registers and then a new arm-with-m-system.xml wrapper file that is like arm-with-m.xml but also xi:includes arm-m-system.xml. Something like: $ diff -up arm-with-m.xml arm-with-m-system.xml arm + Then stubs pick either arm-with-m-system.xml or arm-with-m.xml depending on access to the system registers. Thanks, Pedro Alves