From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63876 invoked by alias); 26 Sep 2019 08:47:30 -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 63863 invoked by uid 89); 26 Sep 2019 08:47:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1 autolearn=ham version=3.3.1 spammy=Gary, gary, nicole, Lau X-HELO: mga18.intel.com Received: from mga18.intel.com (HELO mga18.intel.com) (134.134.136.126) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Sep 2019 08:47:29 +0000 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 01:47:26 -0700 Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga004.fm.intel.com with ESMTP; 26 Sep 2019 01:47:25 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.103]) by IRSMSX153.ger.corp.intel.com ([169.254.9.123]) with mapi id 14.03.0439.000; Thu, 26 Sep 2019 09:47:24 +0100 From: "Metzger, Markus T" To: Andrew Burgess , gdb-patches CC: Simon Marchi , Tom Tromey Subject: RE: [PATCHv3 1/3] gdb: Remove a VEC from gdbsupport/btrace-common.h Date: Thu, 26 Sep 2019 08:47:00 -0000 Message-ID: References: <87lfucf2qs.fsf@tromey.com> <2edcf1984fc1dbe09ceaac8d79f80ca2051e1062.1569455609.git.andrew.burgess@embecosm.com> In-Reply-To: <2edcf1984fc1dbe09ceaac8d79f80ca2051e1062.1569455609.git.andrew.burgess@embecosm.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00508.txt.bz2 Hello Andrew, I can help you run the gdb.btrace suite. Do you have a user branch with th= ese patches? > @@ -1068,13 +1069,12 @@ btrace_compute_ftrace_bts (struct thread_info *tp, >=20 > while (blk !=3D 0) > { > - btrace_block_s *block; > CORE_ADDR pc; >=20 > blk -=3D 1; >=20 > - block =3D VEC_index (btrace_block_s, btrace->blocks, blk); > - pc =3D block->begin; > + const btrace_block &block =3D btrace->blocks->at (blk); > + pc =3D block.begin; We could also turn BTRACE->BLOCKS into a const & outside the loop. > @@ -1581,11 +1580,9 @@ btrace_add_pc (struct thread_info *tp) > pc =3D regcache_read_pc (regcache); >=20 > btrace.format =3D BTRACE_FORMAT_BTS; > - btrace.variant.bts.blocks =3D NULL; > + btrace.variant.bts.blocks =3D new std::vector ; A stack-allocated vector should do. Looks like we leaked the one-entry vector before. =20 > @@ -2052,9 +2048,8 @@ parse_xml_btrace_block (struct gdb_xml_parser *pars= er, > begin =3D (ULONGEST *) xml_find_attribute (attributes, "begin")->value= .get (); > end =3D (ULONGEST *) xml_find_attribute (attributes, "end")->value.get= (); >=20 > - block =3D VEC_safe_push (btrace_block_s, btrace->variant.bts.blocks, N= ULL); > - block->begin =3D *begin; > - block->end =3D *end; > + gdb_assert (btrace->variant.bts.blocks !=3D nullptr); We don't check most pointers in GDB. Besides, we just allocated the vector. The invariant is that if BTRACE->FORMAT =3D=3D BTRACE_FORMAT_BTS, the vector is non-null. > @@ -3095,7 +3090,8 @@ btrace_maint_update_packets (struct btrace_thread_i= nfo > *btinfo, > case BTRACE_FORMAT_BTS: > /* Nothing to do - we operate directly on BTINFO->DATA. */ > *begin =3D 0; > - *end =3D VEC_length (btrace_block_s, btinfo->data.variant.bts.bloc= ks); > + gdb_assert (btinfo->data.variant.bts.blocks !=3D nullptr); See above. More below. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928