From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23521 invoked by alias); 16 Jul 2014 13:01:01 -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 23503 invoked by uid 89); 16 Jul 2014 13:01:00 -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 autolearn=ham version=3.3.2 X-HELO: e06smtp14.uk.ibm.com Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 16 Jul 2014 13:00:54 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 16 Jul 2014 14:00:51 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 16 Jul 2014 14:00:48 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3BE3F2190056 for ; Wed, 16 Jul 2014 14:00:34 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps3074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s6GD0m9q35979462 for ; Wed, 16 Jul 2014 13:00:48 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s6GD0mIu025826 for ; Wed, 16 Jul 2014 07:00:48 -0600 Received: from br87z6lw.de.ibm.com (dyn-9-152-212-196.boeblingen.de.ibm.com [9.152.212.196]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s6GD0kvF025753; Wed, 16 Jul 2014 07:00:47 -0600 From: Andreas Arnez To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jiwang@tilera.com (Jiong Wang) Subject: Re: [PATCH v2 11/13] TILEGX Linux: Fill 'collect_regset' in regset structure. References: <201407151000.s6FA0qeJ008359@d06av02.portsmouth.uk.ibm.com> Date: Wed, 16 Jul 2014 13:30:00 -0000 In-Reply-To: <201407151000.s6FA0qeJ008359@d06av02.portsmouth.uk.ibm.com> (Ulrich Weigand's message of "Tue, 15 Jul 2014 12:00:52 +0200 (CEST)") Message-ID: <87tx6hcvb5.fsf@br87z6lw.de.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14071613-1948-0000-0000-0000008AB9B5 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00419.txt.bz2 On Tue, Jul 15 2014, Ulrich Weigand wrote: > Andreas Arnez wrote: > >> gdb/ >> * tilegx-linux-tdep.c (tilegx_linux_supply_regset): Delete >> function. Move logic to... >> (tilegx_linux_regmap): ... this new register map. >> (TILEGX_GREGS_SIZE): New enum value. >> (tilegx_linux_regset): Refer to register map, replace supply >> method by regcache_supply_regset, and add collect method. > >> +static const struct regcache_map_entry tilegx_linux_regmap[] = >> + { >> + { TILEGX_NUM_EASY_REGS, 0 }, > > Maybe TILEGX_R0_REGNUM instead of 0? Maybe. Or, thinking about this again, I'd more clearly indicate the group of "easy" registers with a new enum value TILEGX_FIRST_EASY_REGNUM = TILEGX_R0_REGNUM OK? > >> + { 1, TILEGX_PC_REGNUM }, > > This seems to get the register size wrong in 32-bit mode; note > that TILEGX_PC_REGNUM has type builtin_func_ptr, which may be > 4 bytes in size ... Hm, I didn't realize that 32-bit mode is actually supported. Note that tilegx_register_type() unconditionally assigns a 64-bit type to *all other* registers: if (regnum == TILEGX_PC_REGNUM) return builtin_type (gdbarch)->builtin_func_ptr; else return builtin_type (gdbarch)->builtin_uint64; Also, the original logic in tilegx_linux_supply_regset() maps an 8-byte slot to each register. In 32-bit mode, this behavior doesn't seem to match the Linux kernel code, which -- if I interpret it correctly -- assigns the same type 'pt_reg_t' to all registers in pt_regs, and: pt_reg_t == uint_reg_t == __uint_reg_t == unsigned long Thus, each register should be in a 4-byte slot, and the register type for everything but the PC should be builtin_uint32, right? Has GDB ever been used for 32-bit TILE-Gx core files? Or am I getting something wrong here? > >> + { 1, TILEGX_FAULTNUM_REGNUM }, >> + { 0 } >> + }; >> >> - if (regnum == gri || regnum == -1) >> - regcache_raw_supply (regcache, gri, ptr); >> - } >> -} >> +enum >> +{ >> + TILEGX_GREGS_SIZE = (TILEGX_NUM_EASY_REGS + 2) * tilegx_reg_size >> +}; > > This doesn't appear to be used here. Removed.