From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88345 invoked by alias); 13 Jan 2020 03:30:57 -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 88336 invoked by uid 89); 13 Jan 2020 03:30:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=hmm X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Jan 2020 03:30:55 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 00D3Uk1g027162 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Jan 2020 22:30:51 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 00D3Uk1g027162 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1578886252; bh=x1XVB49ZDh/BOqRgGfk1wj16wXbCfAHLqTn99FFs0/M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cM9WdMvPB/YSkvWvF6nAPsJpr4cwyK8Y7CjWpT2xE48Jf0WElAh50gDy4dxnR0wyF A73XkQJPVw1AeTwPU2hwT9Qx5/UU7WECj2V3tr/fXahrvKfXNoMXxj1W9eSmpvVZPH 5aO0CTzd0MHRJX5LQ1l25YdnGk0VWZE8QkDCaSuo= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 535681E508; Sun, 12 Jan 2020 22:30:46 -0500 (EST) Subject: Re: [PATCH] gdb: use std::vector instead of alloca in core_target::get_core_register_section To: Christian Biesinger Cc: gdb-patches References: <20200112201729.489317-1-simon.marchi@polymtl.ca> From: Simon Marchi Message-ID: <2131f829-e84a-c45b-06b5-e3ec79a3344c@polymtl.ca> Date: Mon, 13 Jan 2020 04:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00316.txt.bz2 On 2020-01-12 6:20 p.m., Christian Biesinger via gdb-patches wrote: > On Sun, Jan 12, 2020, 15:17 Simon Marchi wrote: > >> As I was trying to compile gdb for an m68k host, I got this error: >> >> CXX corelow.o >> In file included from /binutils-gdb/gdb/gdbsupport/common-defs.h:120, >> from /binutils-gdb/gdb/defs.h:28, >> from /binutils-gdb/gdb/corelow.c:20: >> /binutils-gdb/gdb/corelow.c: In member function 'void >> core_target::get_core_register_section(regcache*, const regset*, const >> char*, int, int, const char*, bool)': >> /binutils-gdb/gdb/../include/libiberty.h:727:36: error: 'alloca' bound is >> unknown [-Werror=alloca-larger-than=] >> 727 | # define alloca(x) __builtin_alloca(x) >> | ~~~~~~~~~~~~~~~~^~~ >> /binutils-gdb/gdb/corelow.c:625:23: note: in expansion of macro 'alloca' >> 625 | contents = (char *) alloca (size); >> | ^~~~~~ >> >> We are using alloca to hold the contents of a the core register >> sections. These sections are typically fairly small, but there is no >> realy guarantee, so I think it would be more reasonable to just use >> dynamic allocation here. >> > > This seems to be in a common file, why did it only fail on m68k? Hmm, I don't really know. I presumed that it's just that this warning was enabled in gcc by default on m68k, and not on other architectures, because it's especially important for architectures with small amounts of memory like m68k. I tried to look in the gcc source and documentation for this, but didn't find anything related to this (I don't know the gcc internals thoug, so I probably didn't look at the right place). When I add -Walloca-larger-than=16 to my x86-64 build, I get the same error. However, note that I only get it when building with -O2 as well. >> gdb/ChangeLog: >> >> * corelow.c (core_target::get_core_register_section): Use >> std::vector instead of alloca. >> --- >> gdb/corelow.c | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/gdb/corelow.c b/gdb/corelow.c >> index c53bf1df8fd8..e7efa652d62a 100644 >> --- a/gdb/corelow.c >> +++ b/gdb/corelow.c >> @@ -594,7 +594,6 @@ core_target::get_core_register_section (struct >> regcache *regcache, >> { >> struct bfd_section *section; >> bfd_size_type size; >> - char *contents; >> bool variable_size_section = (regset != NULL >> && regset->flags & REGSET_VARIABLE_SIZE); >> >> @@ -622,8 +621,8 @@ core_target::get_core_register_section (struct >> regcache *regcache, >> section_name.c_str ()); >> } >> >> - contents = (char *) alloca (size); >> - if (! bfd_get_section_contents (core_bfd, section, contents, >> + std::vector contents (size); >> + if (! bfd_get_section_contents (core_bfd, section, contents.data (), >> > > Since you're touching this, isn't usual style not to have a space after the > ! ? I see it it some spots here and there, but no I don't think it's part of the style we follow. I've removed the space in my local version of the patch, thanks for noticing. Simon