From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89053 invoked by alias); 13 Dec 2016 10:05:39 -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 89031 invoked by uid 89); 13 Dec 2016 10:05:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_50,MIME_QP_LONG_LINE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=U*qiyaoltc, sk:qiyaolt, qiyaoltc@gmail.com, qiyaoltcgmailcom X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Dec 2016 10:05:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8210FC14; Tue, 13 Dec 2016 02:05:26 -0800 (PST) Received: from [10.45.32.207] (e105284-mac.manchester.arm.com [10.45.32.207]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id A2C133F220; Tue, 13 Dec 2016 02:05:25 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.0.161029 Date: Tue, 13 Dec 2016 10:05:00 -0000 Subject: Re: [PATCH 1/8] AARCH64 SVE: Increse max register sizes From: Alan Hayward To: Yao Qi , "gdb-patches@sourceware.org" Message-ID: References: <20161212181032.GC25542@E107787-LIN> In-Reply-To: <20161212181032.GC25542@E107787-LIN> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-SW-Source: 2016-12/txt/msg00278.txt.bz2 I=E2=80=99ve just noticed I forgot to add a changelog for all of my patches. Apologies - I=E2=80=99ll add them for any V2 versions (or happy to repost a= ll of them again with changelogs if required). On 12/12/2016 18:10, "Yao Qi" wrote: >On 16-12-05 12:26:24, Alan Hayward wrote: >> This is part of a series adding AARCH64 SVE support to gdb and >>gdbserver. >>=20 >> In SVE the maximum size of a variable-length vector register is 256 >>bytes, >> four >> times the current maximum size currently supported in gdb. This patch >> increases >> the max register size and max gdbserver buffer size accordingly. > >Joel expressed the willingness that we should make MAX_REGISTER_SIZE >gdbarch specific last time when it was changed from 32 to 64. >https://sourceware.org/ml/gdb-patches/2010-09/msg00245.html >I think we should make MAX_REGISTER_SIZE gdbarch specific, or stop >using it at all. I=E2=80=99m happy to do this if that=E2=80=99s what people want. I avoided = doing it because I didn=E2=80=99t want to subtly break something and it=E2=80=99s going to be = quite a large change - I might submit it a set of patches by itself. > >>=20 >> Alternatively, I could add a target variable using gdbarch.c, however >> there are >> 80+ static arrays within the code using the value, which would all need >> replacing with mallocs/frees. > >We can use alloca to allocate memory on stack, and we can get the >size of a register if gdbarch and regnum is available. For example, >we can replace MAX_REGISTER_SIZE with register_size in >xtensa_pseudo_register_read this way, > > gdb_byte *buf =3D (gdb_byte *) alloca (register_size (gdbarch, >regnum)); > >This can be used many places to replace MAX_REGISTER_SIZE. Hopefully, >this may get rid of the use of MAX_REGISTER_SIZE except the uses in >python/py-unwind.c and remote.c. We may replace array >data[MAX_REGISTER_SIZE] >with pointer in struct cached_reg and struct reg_info, and allocate memory >dynamically, or use std::vector if it helps. > I=E2=80=99ll look into using this. Thanks for the review. Alan.