From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22747 invoked by alias); 22 Oct 2014 10:31: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 22734 invoked by uid 89); 22 Oct 2014 10:31:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-wg0-f47.google.com Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 22 Oct 2014 10:31:52 +0000 Received: by mail-wg0-f47.google.com with SMTP id x13so3382456wgg.18 for ; Wed, 22 Oct 2014 03:31:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KqcXz9hO13yOZ1kDNgyniyIGOudr3CQFl1lUXI5A9J8=; b=fQQnSJi3e3LBagTK+MbT1BudU0KQZb45U/+vQrcNDeOxTRdvWtyfU2aAxdut5N4mcn kax+pGzcSolrkEVhwqEWDniQzuzpjWXAJ/Qc1wOltXeD9y1EO1QYbcJa4hqkTvdJYv6Y D4NQw2hvc92okTbcsetqdi4XurKPoC8c7jgryAzR0mOh/pCvnutt+xHUuFAtZxYDnNQZ IF9QYNAjmqkoduvfpRXngiP9Q/6jM6FC4ZrUak0hyDusEEAwbuKz/6QOHgaA2MOpvp39 mDnj8F/Ebt7ThMc4tDmekuEqxROuv0Hbgif60bcBtwQdV3QQugNazkjwIcXjYrbdfzjQ /bvA== X-Gm-Message-State: ALoCoQnpT5e18EFIukDHpzV8Z+dA3b66qz1UhuPnCDneqcUpL1+6hHU3ACz9Oq7a5asXMjio3qdF X-Received: by 10.194.81.6 with SMTP id v6mr49404829wjx.39.1413973908724; Wed, 22 Oct 2014 03:31:48 -0700 (PDT) Received: from [192.168.106.31] ([193.37.225.80]) by mx.google.com with ESMTPSA id dg3sm1432505wib.14.2014.10.22.03.31.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 03:31:48 -0700 (PDT) Message-ID: <54478792.3050009@my.bristol.ac.uk> Date: Wed, 22 Oct 2014 10:31:00 -0000 From: Christopher Bainbridge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: gdb@sourceware.org Subject: Re: [help] Issues with 'g' packet and MIPS - gdb interprets the packet reply wrong References: <54464055.9020100@my.bristol.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00088.txt.bz2 Many thanks! It turns out that I mistook the M14000 to be the same as the M14k... which, annoyingly, they aren't. So doing: set architecture mips:isa32r2 has solved my problem. Thanks a lot! Chris On 21/10/14 21:34, Maciej W. Rozycki wrote: > Hi Christopher, > >> I am trying to implement a remote stub for a MIPS cpu (using GDB version 7.8). >> When GDB asks for the general registers using the 'g' packet, I reply with: >> >> 00000000000000000d01000000000000fffdffff00000000000000000080c0bf30000000f0fec0bf000000002e0000000000000000000000000000008080808000000000000000000000000000000000000000000000000000000000000000000000000000000000000001800000000000000000e8fec0bf00000000702ec0bf0000000000000000000000000000000000000000702ec0bf >> >> As each register is 32 bits (represented by 8 hex characters), this should be >> all the registers up to and including the PC. > What makes you assume the registers are 32 bits each? > >> However, GDB prints this out: >> >> info reg >> zero at v0 v1 a0 a1 a2 a3 >> R0 00000000 0000010d fffffdff 00000000 00000030 00000000 00000000 00000000 >> t0 t1 t2 t3 t4 t5 t6 t7 >> R8 00000000 00000000 00000000 00000000 00000000 80010000 00000000 00000000 >> s0 s1 s2 s3 s4 s5 s6 s7 >> Sending packet: $p13#d4...Ack >> Packet received: 00000000 >> Sending packet: $p14#d5...Ack >> Packet received: 00000000 >> Sending packet: $p15#d6...Ack >> Packet received: 00000000 >> Sending packet: $p16#d7...Ack >> Packet received: 00000000 >> Sending packet: $p17#d8...Ack >> Packet received: 00000000 >> R16 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> t8 t9 k0 k1 gp sp s8 ra >> Sending packet: $p18#d9...Ack >> Packet received: 00000000 >> Sending packet: $p19#da...Ack >> Packet received: 00000000 >> Sending packet: $p1a#02...Ack >> Packet received: 00000180 >> Sending packet: $p1b#03...Ack >> >> etc >> >> This looks to be that it is determining the size of each register incorrectly, >> and is thus asking for more registers using the 'p' packet. >> >> Is this a bug on my end or in GDB? >> I use the command >> >> set processor mips:14000 >> >> beforehand, as this is the processor we're using. > You mean: > > (gdb) set architecture mips:14000 > > I presume, right? > > The R14000 is a 64-bit processor so its registers are 64-bit and will be > treated as such by default by GDB. You may be able to limit the width of > registers expected by selecting a 32-bit processor instead or by selecting > a 32-bit ABI such as `o32'. The latter can be done with: > > (gdb) set mips abi o32 > > or by selecting a file to debug that has been built for that ABI. > > Please note that this is a grey area though, with a bare-metal stub you > should be really exchanging registers with GDB in their native sizes and > letting GDB truncate and extend them as required depending on the ABI used > by the program being debugged. GDB is already capable of doing that, > however in order to make use of that capability both the stub and GDB > would have to support XML register descriptions which is something that > owing to the vast number of CP0 register set variants in the MIPS > architecture has never been implemented. So in fact you may be hitting > problems regardless of the ABI selection noted above. > > You can always determine the widths of registers GDB expects with the: > > (gdb) maintenance print registers > > command -- see the `Type' column on the right for the internal type used > and note that the registers exchanged with a remote stub are those in the > low half of indices (`Nr' == `Rel'), the so called "raw registers". > > HTH, > > Maciej