From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45252 invoked by alias); 2 Dec 2017 21:49:54 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 45233 invoked by uid 89); 2 Dec 2017 21:49:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=pasted, watch, HContent-Transfer-Encoding:8bit X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 Dec 2017 21:49:51 +0000 Received: from [10.0.0.11] (192-222-251-162.qc.cable.ebox.net [192.222.251.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DE67A1E4F2; Sat, 2 Dec 2017 16:49:49 -0500 (EST) Subject: Re: How can I figure out the register numbers for a remote target stub? To: Sebastian Huber , gdb@sourceware.org, Yao Qi References: <87851068-0256-c35d-00a6-b69b71fe0251@embedded-brains.de> From: Simon Marchi Message-ID: Date: Sat, 02 Dec 2017 21:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87851068-0256-c35d-00a6-b69b71fe0251@embedded-brains.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-12/txt/msg00003.txt.bz2 Hi Sebastian, I am a bit confused myself with register numbering, so I will try to answer your question to the best of my knowledge without sending you on a wrong track. Perhaps Yao in CC can clarify, since he works quite a lot on regcaches. On 2017-11-29 05:53 AM, Sebastian Huber wrote: > Sorry for the bad format in the previous mail. Here is the next attempt: > > I would like to extend the RTEMS GDB remote target stub to support > PowerPC (e500, e6500).  In the ARM support we have some magic register > numbers: > > https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n132 > > > /* >  * Debugger registers layout. >  */ > #define REG_R0 0 > #define REG_R1 1 > #define REG_R2 2 > #define REG_R3 3 > #define REG_R4 4 > #define REG_R5 5 > #define REG_R6 6 > #define REG_R7 7 > #define REG_R8 8 > #define REG_R9 9 > #define REG_R10 10 > #define REG_R11 11 > #define REG_R12 12 > #define REG_SP 13 > #define REG_LR 14 > #define REG_PC 15 > #define REG_CPSR 25 > > How can I find the corresponding numbers for the PowerPC? There is a > comment in (gdb/ppc-tdep.h): > > /* Register number constants. These are GDB internal register numbers; > they are >  * not used for the simulator or remote targets. Extra SPRs (those > other than >  * MQ, CTR, LR, XER, SPEFSCR) are given numbers above PPC_NUM_REGS. So are >  * segment registers and other target-defined registers. */ > enum { >   PPC_R0_REGNUM = 0, >   PPC_F0_REGNUM = 32, > > I cannot find the numbers which are used for remote targets. Are they > defined by the XML files in gdb/features/rs6000? You can use the command "maintenance print raw-registers" at any time to see the format of the raw register buffer expected by GDB. The output also includes the register number (not sure which one). For example: (gdb) set architecture powerpc:e500 The target architecture is assumed to be powerpc:e500 (gdb) maintenance print raw-registers Name Nr Rel Offset Size Type Raw value r0 0 0 0 4 uint32_t r1 1 1 4 4 uint32_t r2 2 2 8 4 uint32_t ... pc 64 64 128 4 *1 msr 65 65 132 4 uint32_t cr 66 66 136 4 uint32_t lr 67 67 140 4 *1 ctr 68 68 144 4 uint32_t xer 69 69 148 4 uint32_t ... The offsets and sizes indicate the format of the expected reply to the g packet. Watch out though, for some reason the "maintenance print raw-registers" command lists the cooked registers at the end: ... ev0 174 0 292 8 ppc_builtin_type_vec64 ... Those registers should not be included in the response to the 'g' packet. Those numbers seem to match the numbers in ppc-tdep.h, I suppose that's not a coincidence. If you do the same command but for the arm architecture, the numbers will match the numbering you pasted above. But it's the part that really confuses me, there are multiple kinds of register numbers, and it's not clear to me who assigns them. Simon