From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20797 invoked by alias); 12 Jan 2020 23:20:59 -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 20789 invoked by uid 89); 12 Jan 2020 23:20:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-29.4 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=touching, H*c:alternative, H*RU:209.85.210.66, HX-Spam-Relays-External:209.85.210.66 X-HELO: mail-ot1-f66.google.com Received: from mail-ot1-f66.google.com (HELO mail-ot1-f66.google.com) (209.85.210.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 12 Jan 2020 23:20:57 +0000 Received: by mail-ot1-f66.google.com with SMTP id z9so5227245oth.5 for ; Sun, 12 Jan 2020 15:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YSnadoimTmTfNW5jwuUPnLPNNbwHhx3TG7+4d9sZzFM=; b=dMY07MkXrRxHJtUfO5zQM242nGn/HHcOk8YDSokRPSkxpJc6zZyFaiu0LRtZqb4FpY 0n8/NMpt0GGgZ7ggR4MyC/vYGvxOds3rJNnpxpUZo7s7S7OWzoP3Mbu2bZ3uWWgrE/E9 6DRPazEo8N7rb9siTS9fsq1JTwwVOSzyG84LJO7JyvICfzfC65NEygzRE673N/z4jjG2 JwLRdy7Ukr88ToFAFq0KkjYbMPfJoZZcAhmaDdQ6ruDKO67CMwMCuc9+7c4gco4YlGJI 0ewM3OpgHFj+VboyfdBg8Hetiz+jjtcRLBOUDzOxvkFg96Z+cLbzq72vyeN9+CbrGE59 1f8w== MIME-Version: 1.0 References: <20200112201729.489317-1-simon.marchi@polymtl.ca> In-Reply-To: <20200112201729.489317-1-simon.marchi@polymtl.ca> From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Mon, 13 Jan 2020 03:30:00 -0000 Message-ID: Subject: Re: [PATCH] gdb: use std::vector instead of alloca in core_target::get_core_register_section To: Simon Marchi Cc: gdb-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00315.txt.bz2 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? > 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 ! ? (file_ptr) 0, size)) > { > warning (_("Couldn't read %s registers from `%s' section in core > file."), > @@ -633,12 +632,12 @@ core_target::get_core_register_section (struct > regcache *regcache, > > if (regset != NULL) > { > - regset->supply_regset (regset, regcache, -1, contents, size); > + regset->supply_regset (regset, regcache, -1, contents.data (), > size); > return; > } > > gdb_assert (m_core_vec != nullptr); > - m_core_vec->core_read_registers (regcache, contents, size, which, > + m_core_vec->core_read_registers (regcache, contents.data (), size, > which, > (CORE_ADDR) bfd_section_vma (section)); > } > > -- > 2.24.1 > >