From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61431 invoked by alias); 27 Jan 2017 11:49:25 -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 60635 invoked by uid 89); 27 Jan 2017 11:49:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=aarch64-tdep.c, UD:aarch64-tdep.c, sk:801c03d, aarch64tdepc 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 ESMTP; Fri, 27 Jan 2017 11:49:23 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 77321C7043; Fri, 27 Jan 2017 11:49:23 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0RBnFpA003322; Fri, 27 Jan 2017 06:49:22 -0500 Subject: Re: [PATCH] Removal of uses of MAX_REGISTER_SIZE To: Alan Hayward , "gdb-patches@sourceware.org" References: <7CF07197-4FED-4970-BB4B-2FE828E29A63@arm.com> Cc: nd From: Pedro Alves Message-ID: <8d293f49-6337-4164-3027-30c333e31d58@redhat.com> Date: Fri, 27 Jan 2017 11:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7CF07197-4FED-4970-BB4B-2FE828E29A63@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00614.txt.bz2 On 01/24/2017 10:31 AM, Alan Hayward wrote: > This patch replaces all current uses of MAX_REGISTER_SIZE with calls to > either register_size() when the register number is known, and > max_register_size() in all other cases. > > It assumes that the patch "[PATCH 3/3] Calculate max register size" will be > approved, and follows the methods used in that series of 3 patches. > > In a couple of cases I've moved variables outside a loop to prevent multiple > allocations. The very first hunk calls alloca in a loop (I didn't look any further). This is unfortunately easy to get wrong with alloca. (Not just in this patch, but also future patches that might move things around and add loops around allocas without noticing.) Wish the compiler warned about it and/or that C++ supported VLAs. :-/ > index 801c03d5a0b5d205dc967cb0d53e299ea95eaa8f..a317c8f2bb192fc25689c84375b8c7bb327dd596 100644 > --- a/gdb/aarch64-tdep.c > +++ b/gdb/aarch64-tdep.c > @@ -1982,7 +1982,8 @@ aarch64_store_return_value (struct type *type, struct regcache *regs, > for (i = 0; i < elements; i++) > { > int regno = AARCH64_V0_REGNUM + i; > - bfd_byte tmpbuf[MAX_REGISTER_SIZE]; > + bfd_byte *tmpbuf = (bfd_byte *) alloca (register_size (gdbarch, > + regno)); > > if (aarch64_debug) > { Thanks, Pedro Alves