From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28911 invoked by alias); 21 Oct 2014 11:15:44 -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 28901 invoked by uid 89); 21 Oct 2014 11:15:43 -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-wi0-f171.google.com Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 21 Oct 2014 11:15:41 +0000 Received: by mail-wi0-f171.google.com with SMTP id em10so9706597wid.16 for ; Tue, 21 Oct 2014 04:15:38 -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 :subject:content-type:content-transfer-encoding; bh=Zhcf73e+qAqPSnfEhKsMs/oQ+HucgiEwQNnXe+RPUQA=; b=DvRe8g43igNo9CWJulOUwaxHWWuToiKw7f484baF6dWjmMCorjJoYs5R649lbfYRe7 K8fmko2yX/BnbvUCceKKDYRmmnMUdHLoLukq0fDElR/bi+XvWtoYUTnHUYRGORwFp9Zl Zdn9WtmOtMvCLq3glC95HOPOSKDE5oXPCPgsPtfJ/UMcZRpKgSi1CvnDErKYRJmBoqz4 6n4TMVUHDU8+V5ywZck7XU+YXFKJzf99glJW+fK8Crtqxhq6CymDmPnPB4spd6oGbCeX XiaQMkfgCh7f5P8RWbyGuuBtav3MmmCRnyjRdYMhaTO8n5fJvGAaL+FdJ2W/lwnYWbwv SriQ== X-Gm-Message-State: ALoCoQmP7hPrZGD2DJG64XB35yQfT4s9V9TdOfA4Aa/OKl32NXEBqcL2UG4SxiIfwGX+62cjyZc7 X-Received: by 10.180.36.48 with SMTP id n16mr28573558wij.6.1413890137534; Tue, 21 Oct 2014 04:15:37 -0700 (PDT) Received: from [192.168.106.31] ([193.37.225.80]) by mx.google.com with ESMTPSA id k10sm15032120wjb.28.2014.10.21.04.15.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Oct 2014 04:15:36 -0700 (PDT) Message-ID: <54464055.9020100@my.bristol.ac.uk> Date: Tue, 21 Oct 2014 11:15: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: gdb@sourceware.org Subject: [help] Issues with 'g' packet and MIPS - gdb interprets the packet reply wrong Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00084.txt.bz2 Hi all, 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. 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. Thanks, Chris