From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57549 invoked by alias); 9 Jun 2017 13:23:36 -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 57351 invoked by uid 89); 9 Jun 2017 13:23:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=msa, MSA X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 13:23:33 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 4798F54DE0E1E; Fri, 9 Jun 2017 14:23:32 +0100 (IST) Received: from [10.20.78.166] (10.20.78.166) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Fri, 9 Jun 2017 14:23:34 +0100 Date: Fri, 09 Jun 2017 13:23:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: Alan Hayward , Yao Qi , "gdb-patches@sourceware.org" , nd Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (4/4) In-Reply-To: Message-ID: References: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> <86y3v7uf9j.fsf@gmail.com> <0150DDF9-6204-4F4F-99E9-D757C1DBD512@arm.com> <434A7317-C19A-4B53-8CB1-C7B4ACEC7D17@arm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2017-06/txt/msg00235.txt.bz2 On Fri, 9 Jun 2017, Pedro Alves wrote: > > Hmm, `alloca' then? It used to be used here actually, up till commit > > d9d9c31f3130 ("MAX_REGISTER_RAW_SIZE -> MAX_REGISTER_SIZE"), > > . > > IMO, alloca calls are a red flag, which force you to reason about > whether you're dangerously calling it in a loop such as in > this case, because alloca memory is unwound on function exit, not > scope exit. This is both a concern when an alloca call is > introduced, and later when code is moved around/refactored. If we know > the hard upper bound, and it's just 8 bytes, I don't see the point > of making it variable. Alignment and padding for following > variables plus the magic needed to handle variable length frames end up > negating the saving anyway. Also, the function already hardcodes "8" > in several places. IMO, here it'd be better to keep it simple > and use a static upper bound. Contrariwise `mips_read_fp_register_single' already uses `alloca' for a similar purpose. Good point about the loop though; moving the declaration and allocation outside the loop will easily solve the problem however. Hardcoding things, and especially with literals, causes a maintenance pain when things change. Bad code elsewhere is not an excuse; besides, the other places where `8' is hardcoded are not (buffer) limits, but just handle specific register sizes, which are not going to change, and which are a completely different matter. So if you find `alloca' unacceptable, then the limit has to be a macro, and an assertion check is also due (as already proposed), preferably using `sizeof', so that a future change does not break it by accident. NB the MSA ASE expands FPRs to 16 bytes and we'll soon have to accomodate that; patches have already been posted and are being worked on. Maciej