From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100409 invoked by alias); 7 Apr 2017 16:04:34 -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 100363 invoked by uid 89); 7 Apr 2017 16:04:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=claim X-HELO: mail-wr0-f195.google.com Received: from mail-wr0-f195.google.com (HELO mail-wr0-f195.google.com) (209.85.128.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 16:04:31 +0000 Received: by mail-wr0-f195.google.com with SMTP id t20so20927380wra.2 for ; Fri, 07 Apr 2017 09:04:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=OREqGXO450O2Dwcr75fE7VikVR0Llw+dD/hraZ6/JoI=; b=nujnr3Bb/OyyNGn9b1G1q9FX19M+Pi2DkzYkt65Eamo+a5F2yPr9+SBVX2uGdzDuNA cs1MmM/L1C2JwbikET6ixeGzOx4Mkll/I3PJrLZjRgQmCgMago7WftjohRfeWliKElHn FDfaxNQnWcQoWGgIBoBrNDgdtiuTVakWCpfB7EEfO9jnoNmn1T7UyfKqeH82DZ4gDLLF OH4NNcgNRBJZr2D9ONZi3vbX5s4Axe55d83Io7ROvsqhQLOIEweK2RdpDFwJ0aknFxp0 QDrfPyGg2J7kp1sPrZVNewssU7zhk6UlUaqJ9ZgkQ47rpjFQmUl5VuZeoQEH6givATDs 4N7w== X-Gm-Message-State: AFeK/H0I2Vh64GOheEYCdKwVx0CRLPh/1U4m3TYm2lc6GiOM0daPBm9HrBEA6EfJI7PlFw== X-Received: by 10.223.146.164 with SMTP id 33mr35764306wrn.17.1491581071212; Fri, 07 Apr 2017 09:04:31 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id i7sm6775270wmg.30.2017.04.07.09.04.30 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 07 Apr 2017 09:04:30 -0700 (PDT) From: Yao Qi To: Alan Hayward Cc: Pedro Alves , "gdb-patches\@sourceware.org" , Subject: Re: [PATCH 7/11] Add BFIN_MAX_REGISTER_SIZE References: <3239de71-1e7c-22dd-172d-56a3baad292b@redhat.com> Date: Fri, 07 Apr 2017 16:04:00 -0000 In-Reply-To: (Alan Hayward's message of "Wed, 5 Apr 2017 15:51:40 +0000") Message-ID: <861st4jjaq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00174.txt.bz2 Alan Hayward writes: > There is some existing code in regcache.c that checks that no register in= the > target descriptor is greater than MAX_REGISTER_SIZE. > Obviously, this code will vanish when MAX_REGISTER_SIZE disappears. > > If people think that this is an important check to have, then maybe there= needs > to be an additional patch set. For each target with a FOO_MAX_REGISTER_SI= ZE, > in the init code for that target add: > gdb_assert (FOO_MAX_REGISTER_SIZE >=3D max_register_size (gdbarch)); > ? It is not just about checking. What if the assert fail? FOO_MAX_REGISTER_SIZE is a strong claim for arch FOO. That is why I suggested "or we can define ASTAT_REGISTER_SIZE". > > (To keep this simple I=E2=80=99d do it after adding these patches which a= dd > FOO_MAX_REGISTER_SIZE). --=20 Yao (=E9=BD=90=E5=B0=A7)