From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8VUG-0000vI-UC for qemu-devel@nongnu.org; Mon, 14 Dec 2015 10:56:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8VUD-0003eF-Nq for qemu-devel@nongnu.org; Mon, 14 Dec 2015 10:56:32 -0500 Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:36136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8VUD-0003e6-6q for qemu-devel@nongnu.org; Mon, 14 Dec 2015 10:56:29 -0500 Received: by mail-wm0-x232.google.com with SMTP id n186so124647437wmn.1 for ; Mon, 14 Dec 2015 07:56:28 -0800 (PST) References: <1450074970-28562-1-git-send-email-chrisfriedt@gmail.com> <1450074970-28562-2-git-send-email-chrisfriedt@gmail.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Mon, 14 Dec 2015 15:56:25 +0000 Message-ID: <874mflgh1y.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Christopher Friedt , QEMU Developers , Richard Henderson Peter Maydell writes: > On 14 December 2015 at 14:22, Christopher Friedt wrote: >> On Mon, Dec 14, 2015 at 8:16 AM, Christopher Friedt >> wrote: >>> On Mon, Dec 14, 2015 at 8:14 AM, Peter Maydell wrote: >>>> Note that our XML files are from gdb itself, so you should start >>>> by checking whether gdb has a suitable Cortex-M xml file. >>> >>> They do indeed. Thanks for the tip. >> >> binutils-gdb arm-m-profile.xml: https://goo.gl/hpTye8 >> openocd armv7m.c: http://goo.gl/FFn56X >> >> There are 2 (major) differences from what I've seen: >> >> 1) xpsr is regnum 25 instead of 16 (what OpenOCD uses), and I'm fine with that. >> 2) binutils-gdb does not specify anything for the >> org.gnu.gdb.arm.m-system group of core registers in any xml file. >> >> It also seems very clear that the binutils people and the openocd >> people have diverged at some point in their assignment of regnum >> values; in openocd, the registers are mostly all consecutive with >> moderate reuse between cores, whereas in binutils-gdb, their are >> occasional gaps and extensive reuse between cores. The differences >> seem primarily technical, but it's unclear as to why binutils-gdb does >> *not* include the m-system group of core registers. > > My guess would be because gdb is primarily thinking of itself > as a user-mode debugger, and system registers aren't accessible > from there. And/or "nobody asked for it". > >> The m-system group of core registers are *incredibly* useful, but I'm >> also inclined not to clobber binutils-gdb's register numbering >> convention. >> >> I think it would be most ideal to append the crucial m-system >> information directly [1] in arm-m-profile.xml from binutils-gdb (or >> possibly declare it as an include [2]): >> >> >> >> >> >> >> >> >> >> >> However, if the worry there is that it diverges from binutils-gdb, >> then the next best solution would be to create a separate >> arm-m-system.xml, and to append that to the cpu->gdb_reg linked list >> in cortex_m3_initfn(), cortex_m4_initfn(), and any other m's [3]. >> >> Which solution would work best for qemu? > > I'd rather we didn't diverge from upstream gdb too. On the > other hand I'm not sure how much it matters if we all end up > using different XML to describe the same target hardware. It > would be nice to ask the gdb folks first though, maybe. > > rth: do you know how this stuff works? IIRC last time I played with this when adding aarch64 system registers for debugging is the number is irrelevant to gdb, its all dependant on what the stub sends. As long as the coprocessor get/set functions agree on the order with the xml everything should be fine. > > thanks > -- PMM -- Alex Bennée