From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58259 invoked by alias); 3 Feb 2017 16:50:30 -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 58142 invoked by uid 89); 3 Feb 2017 16:50:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Ensuring, Hx-languages-length:1720, H*f:sk:0C6A0D5, H*i:sk:0C6A0D5 X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Feb 2017 16:50:27 +0000 Received: by mail-wm0-f67.google.com with SMTP id r18so5533063wmd.3 for ; Fri, 03 Feb 2017 08:50:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=phKUxcMfTI8dnLq5q/2fqkXdB9rUIy2nU52gyQmj/3o=; b=feqbi1YS6Dq7XHwsBii2phHDN2dVm/2Fh2KWsYDFD8eeZQqXUEj2w1H/Q0ZkO0bZH3 ePncl3TrAhEKDf10/AaEYqIkOsTduqZWGybhaMk/ACBD01nVbe3sfGJCdc6iRg+H5IKN OiiFsXQ012qFc6mtogAUmAef7AirkPsC9rKhjVlh0oXdJQVC8EIMGg9w+fkMo3DvUEAC QMJHCxVcMEpqzb7RmsNiLuUJ3gba3jYEhdJpG+gKE9nGufEhwUiySVoUwFgLna/sbCIN JrtUhXcoEPuXqqeFSWwAXQJ58CexZ0laG7cqtSq6vUreFQ+nQrm3fW1WLsGOUhIcepfl K6Gw== X-Gm-Message-State: AMke39kUldWdtQtd7klNH8TpAvbCySB/kcI4hLot0WSy0zx1jDtsPamOw7lShnDFbF+Dwg== X-Received: by 10.28.169.142 with SMTP id s136mr2227574wme.9.1486140625661; Fri, 03 Feb 2017 08:50:25 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id 18sm45961268wrb.14.2017.02.03.08.50.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 03 Feb 2017 08:50:25 -0800 (PST) Date: Fri, 03 Feb 2017 16:50:00 -0000 From: Yao Qi To: Alan Hayward Cc: Pedro Alves , Joel Brobecker , "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH] Removal of uses of MAX_REGISTER_SIZE Message-ID: <20170203165022.GB11916@E107787-LIN> References: <7CF07197-4FED-4970-BB4B-2FE828E29A63@arm.com> <45e3a5e1-a9aa-1bc0-5d08-526b89fc458e@redhat.com> <20170201124123.GA27498@E107787-LIN> <20170202094012.dge4r6rsl2skdrii@adacore.com> <20170203102819.GA11916@E107787-LIN> <25716edf-096e-20c5-4170-fb8ca04d897b@redhat.com> <0C6A0D51-4C49-4400-8C46-E77DD512DF56@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0C6A0D51-4C49-4400-8C46-E77DD512DF56@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00100.txt.bz2 On 17-02-03 11:25:43, Alan Hayward wrote: > If someone can ok the common patch, then I’ll make a second patch with the > replacement of all remaining uses of MAX_REGISTER_SIZE in common code. I'd like to do it in an iterative way, start from some simple places, like arm, aarch64, and i386, in which you don't need to define new macros. Then, move to some *-tdep.c and *-nat.c, define ${ARCH}_MAX_REGISTER_SIZE when necessary. Finally, figure out how to remove MAX_REGISTER_SIZE from arch-independent code. > Ensuring it’s not used in common code will allow me to continue moving with the > aarch64 SVE code. > > > There are quite a lot of arch specific functions where we have a register number > from which the register size could be extracted. Eg: > > void > SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache, > int regnum, const gdb_byte *buf) > { > gdb_byte raw_buf[MAX_REGISTER_SIZE]; > > > This could become: > > void > SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache, > int regnum, const gdb_byte *buf) > { > gdb_byte buf[SOMEARCH_MAX_REGISTER_SIZE]; > > > Or: > > void > SOMEARCH_pseudo_register_write (struct gdbarch *gdbarch, struct regcache *regcache, > int regnum, const gdb_byte *buf) > { > std::vector buf (register_size (gdbarch, regnum)); > > > I suspect people will want the first approach? It will result in quite a few new > defines - ALPHA_MAX_REGISTER_SIZE, PPC_MAX_REGISTER_SIZE etc etc. > That is fine, we've already had I386_MAX_REGISTER_SIZE and M68K_MAX_REGISTER_SIZE. However, I think that we only have to add these macros when necessary. -- Yao (齐尧)