From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82110 invoked by alias); 9 Jun 2017 12:05:13 -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 80665 invoked by uid 89); 9 Jun 2017 12:05:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f179.google.com Received: from mail-wr0-f179.google.com (HELO mail-wr0-f179.google.com) (209.85.128.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 12:05:11 +0000 Received: by mail-wr0-f179.google.com with SMTP id g76so30634959wrd.1 for ; Fri, 09 Jun 2017 05:05:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=H8FX1kHSOnrhQ6tqMk4hOkozrxzTzF7jLkYnCYUOxKI=; b=sHS2moXJy9bP28R1uq11YJBR2+5c9Jdt9fNIWqbrmncSgLfOt/j+bjUL23mbma/WjX a+igEOKiolim4dsY1NFyhRpnLjmq/Has4bg/Pim2AiEwthP9RsB9o0pSRRucNn/pZ63C 07UCAbn3YqgeUEjt3Yg3+JtElpSz0ArxMYTmMmGmZ1dTS7+efScC4Z0L/x65+qlpbrmx JE8NMA8nwoB4d/P2Cb+dPI7MZNv7ttYBj2umI0jbg/7aatK9UO9S4Xuzzq5nXYfbMWgp D+kHHiczq/hO7gm1wbJEoGRiKFSnAFWbgPq8sf07rifFhvhCnXICeBc85LXcu3iPY2Ty JL7g== X-Gm-Message-State: AODbwcA9K/ghkS6cRWPOA7eDxDxdjsDSNdH8nsAEHQzBjhFBTL0bZoQa wf3ymX52oTv6IXZ4 X-Received: by 10.28.230.155 with SMTP id e27mr6970115wmi.57.1497009914029; Fri, 09 Jun 2017 05:05:14 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id w18sm1402452wmw.26.2017.06.09.05.05.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 05:05:13 -0700 (PDT) Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (4/4) To: "Maciej W. Rozycki" 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> Cc: Alan Hayward , Yao Qi , "gdb-patches@sourceware.org" , nd From: Pedro Alves Message-ID: Date: Fri, 09 Jun 2017 12:05: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-06/txt/msg00233.txt.bz2 On 06/09/2017 12:48 PM, Maciej W. Rozycki wrote: > On Fri, 9 Jun 2017, Pedro Alves wrote: > >>> I’ve avoided using variable-length arrays because it has the potential to >>> break the stack. >>> However, here we know that we aren’t going to get a value >8, so maybe in >>> this case a VLA would be ok? >>> >>> Anyone else have an opinion here? >> >> VLAs are not standard C++, unfortunately. Do we know whether all compilers >> we care about support them? It doesn't seem worth it to me to rely >> on compiler extensions when we know we're always going to see a size <=8. > > 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. Thanks, Pedro Alves