From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25774 invoked by alias); 16 Sep 2014 17:04:33 -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 25756 invoked by uid 89); 16 Sep 2014 17:04:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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, 16 Sep 2014 17:04:31 +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 (8.14.4/8.14.4) with ESMTP id s8GH4PKk019981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 16 Sep 2014 13:04:26 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8GH4M4n002761; Tue, 16 Sep 2014 13:04:23 -0400 Message-ID: <54186D95.4000301@redhat.com> Date: Tue, 16 Sep 2014 17:04:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Ajit Kumar Agarwal , Michael Eager , Joel Brobecker CC: "gdb-patches@sourceware.org" , Vinod Kathail , Vidhumouli Hunsigida , Nagaraju Mekala Subject: Re: [Patch, microblaze]: Port of Linux gdbserver References: <2570e3c7-f55b-45cd-aa6e-7f4fa145f32a@BN1BFFO11FD002.protection.gbl> <541052B5.5080503@eagercon.com> <20140910134606.GO28404@adacore.com> <050c6461-c35c-441d-9b63-7636d9164e2e@BL2FFO11FD048.protection.gbl> <20140910144313.GP28404@adacore.com> <89d100d8-4ebd-4f50-b5e9-59312124db6a@BL2FFO11FD057.protection.gbl> <54131362.1050009@eagercon.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00545.txt.bz2 On 09/16/2014 07:41 AM, Ajit Kumar Agarwal wrote: >>> >>This is identical to microblaze-with-stack-protect.c. Both specify tdesc_create_feature (result, "org.gnu.gdb.microblaze.core"); >>> >>Why is this needed? > This is needed as gdbserver code expects the register pc as "pc" instead of "rpc" for baremetel. The microblaze-linux-core.xml is changed from "rpc" to "pc" for gdbserver code to work. This doesn't make much sense to me. Can you expand please? Why would you want the register to be named differently on Linux? We've defined the org.gnu.gdb.microblaze.core with "rpc", presumably because that's what the architecture calls that core register. Not reporting all the registers with the exact names GDB reports should be making GDB consider the description invalid. Aren't you seeing that happen? /me looks at code Oh, microblaze_gdbarch_init is incomplete... /* Check any target description for validity. */ if (tdesc_has_registers (tdesc)) { const struct tdesc_feature *feature; int valid_p; int i; feature = tdesc_find_feature (tdesc, "org.gnu.gdb.microblaze.core"); if (feature == NULL) return NULL; tdesc_data = tdesc_data_alloc (); valid_p = 1; for (i = 0; i < MICROBLAZE_NUM_CORE_REGS; i++) valid_p &= tdesc_numbered_register (feature, tdesc_data, i, microblaze_register_names[i]); feature = tdesc_find_feature (tdesc, "org.gnu.gdb.microblaze.stack-protect"); if (feature != NULL) { valid_p = 1; valid_p &= tdesc_numbered_register (feature, tdesc_data, MICROBLAZE_SLR_REGNUM, "rslr"); valid_p &= tdesc_numbered_register (feature, tdesc_data, MICROBLAZE_SHR_REGNUM, "rshr"); } } Note nothing is done with valid_p. It's write-only. Compare with other ports, like arm-tdep.c or mips-tdep.c. Thanks, Pedro Alves