From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35282 invoked by alias); 11 Sep 2018 13:51: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 35265 invoked by uid 89); 11 Sep 2018 13:51:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Attached, blow, day X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Sep 2018 13:51:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F1C361179DB; Tue, 11 Sep 2018 09:51:04 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MkW9UjCW1QD7; Tue, 11 Sep 2018 09:51:04 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 17CF711794F; Tue, 11 Sep 2018 09:51:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 37C8083B28; Tue, 11 Sep 2018 15:51:01 +0200 (CEST) Date: Tue, 11 Sep 2018 13:51:00 -0000 From: Joel Brobecker To: Simon Marchi Cc: gdb-patches@sourceware.org, Jerome Guitton Subject: Re: [RFA v2] arm-pikeos: software single step Message-ID: <20180911135101.GE3379@adacore.com> References: <20180910174345.GD3234@adacore.com> <1536604744-3814-1-git-send-email-y> <20180911085612.GA3379@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-09/txt/msg00333.txt.bz2 > > Attached is the patch I am testing. I am wondering if this is the best > > way, though. What do you think? > > It looks good to me. You could use a range-for, because it's cool: > > for (asymbol *sym : symbol_table) > > but what you have is also fine. Unfortunately, it looks like the change is causing regressions, and it is a bit obscure at the moment, which is not entirely surprising when one deals with memory. > > One question I asked myself is whether we needed the std::vector at > > all, as the building of the vector is a bit clunky in this situation. > > As I understand it, this is mostly to automate the destruction of > > the array. I was wondering whether we could do without the std::vector > > entirely, and just handle the array without a cleanup, since the code > > is simple enough that we can make sure it doesn't throw (I was hoping > > that eg marking the function noexcept would help guaranty that). But > > at the end of the day, although it's manageable in this case, I felt > > it was better to go with the safer approach. > > Well, it would be fine to not use a vector, but in any case I would > recommend the use of an object that ensures the memory is de-allocated in > any case, whether it is an std::vector, an std::unique_ptr or a > gdb::unique_xmalloc_ptr. I don't see any advantage of doing a manual free > over using one of those. > > An alternative would be to use a VLA: > > asymbol *symbol_table[max_number_of_symbols]; > > which I think ends up being like an alloca. But in this case there could be > a huge number of symbols I suppose, so I would avoid that. Yes, the table might be too large and blow the stack. All things considered, I think the better model here seems to be to use a gdb::unique_xmalloc_ptr. I tried that, and the code looks simpler, but I get the same kind of regressions as above. And unfortunately at this point, I have to hold off for a while, because I am out of license, and then I will be traveling home. But thanks a lot for all the feedback received so far; when I pick things up again, I will not be starting from scratch. -- Joel