From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58727 invoked by alias); 26 Sep 2019 02:52:55 -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 58718 invoked by uid 89); 26 Sep 2019 02:52:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1120 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Sep 2019 02:52:53 +0000 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2BD391E4A4; Wed, 25 Sep 2019 22:52:52 -0400 (EDT) Subject: Re: [PATCHv3 0/3] Remove some uses of VEC To: Andrew Burgess , gdb-patches Cc: Tom Tromey References: <87lfucf2qs.fsf@tromey.com> From: Simon Marchi Message-ID: <305c7eed-1ec5-1d49-f2ce-5edb232f6ebe@simark.ca> Date: Thu, 26 Sep 2019 02:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00501.txt.bz2 On 2019-09-25 7:59 p.m., Andrew Burgess wrote: > Tom raised some good points about patch #3, specifically that some of > the query functions like VEC_length and VEC_empty will return a sane > answer even when the vector pointer is NULL. He also pointed out that > VEC_free resets theh vector pointer back to NULL. > > This revision of the series is a little more defensive about checking > for the std::vector pointer being null before dereferencing it. In > places where I'm reasonably sure the vector pointer won't be NULL I've > added an assert - then at least if I'm wrong we'll get a nice error > rather than a random crash. Oh, that's a good point. I gave a quick look at patches 1 and 2, and they seem good with the extra checks. About testing, the testsuite contains a bunch of btrace tests in gdb.btrace, and some more in gdb.python. It would be good to run those tests on a CPU that supports Intel BTS and PT (which would mean any Broadwell or more recent CPU) and a GDB linked against libipt. I can give it a try if you are unable to do it for some reason. Simon