From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 961113858412 for ; Mon, 19 Dec 2022 14:51:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 961113858412 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671461473; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/1BYYaUGhq4+ZkgpQMcZtQCqjHpbYMSTnA/XIb9j2GA=; b=e0nmnGW1dpjvqIS4JTZB34722DkyaHHV80QgOac0LZfucNAt/KDKerjm9y5opPvvpprOf/ k9zp1L42vPJ8s5zasJatBvrRk+Flvsv9vUnBiTOwc866m0n4HllR5M8XftaYoztPQeNkXT 51VFndd76Deo1VT3ojJvxQP7K/5mKao= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-212-dK2TuyiyMTisXxs8txrKiA-1; Mon, 19 Dec 2022 09:51:11 -0500 X-MC-Unique: dK2TuyiyMTisXxs8txrKiA-1 Received: by mail-wm1-f72.google.com with SMTP id 125-20020a1c0283000000b003d1d8d7f266so5236555wmc.7 for ; Mon, 19 Dec 2022 06:51:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/1BYYaUGhq4+ZkgpQMcZtQCqjHpbYMSTnA/XIb9j2GA=; b=i6/ZBUvDw9JoMdiq0MX177ZXpthDOfT1s61i1DPYuGRsdYPkOhNpY9N41vW+x5PsbH izi5jJgRTZilZp5XZ5PLBQVN+LyCewBARqKuEa/v5CR8tNSe1D2VCaeDsi1c1lXuVuKv Cgj7XeqrNWNH88z+AfI4OfZO9qPnkacYTXix5miPdaBmOX0Pug9Pg2gV1WHDZ9PnNME2 YythX0td7+GZ2Udk8WTkaI6+cNCwXGHETdncZqk32m4uw4vmAdHxzKt1Zvz43jAHe9fF jAwR5DNFA4zfBRQ0rdPDKUeKUzcoblGXi+M0B3WISLg3QkQ7IRMcAB7QA38bV59D9sAt D/8Q== X-Gm-Message-State: ANoB5pkDJPybMEF3pwDxz2liPkfWkI0KJBGvmWm2mHuA6SecJtv/EFST sLq4T5iPxS5mgN1KDsHt2GRCnG2BiPKStBfk7g0qVn3wW+mDGE4rY3fWBUUhayHDY3t+ntBFB1X T314U6rAMS0dBKTTRT0U2POqyLPsaomYgzs7iUcmWfVrA2xi43pXfZWtPAI+OR3lSBGQbWfLzLA == X-Received: by 2002:a5d:4746:0:b0:242:931:6f63 with SMTP id o6-20020a5d4746000000b0024209316f63mr26943925wrs.64.1671461469790; Mon, 19 Dec 2022 06:51:09 -0800 (PST) X-Google-Smtp-Source: AA0mqf6aGxm3tHkmQrHqiAixgH5bcw+VCsGkg4o7GGWqgb8nXXMc6TCBC61rnvmMgdPmecxAj2Ukiw== X-Received: by 2002:a5d:4746:0:b0:242:931:6f63 with SMTP id o6-20020a5d4746000000b0024209316f63mr26943914wrs.64.1671461469509; Mon, 19 Dec 2022 06:51:09 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id w13-20020a5d4b4d000000b00242246c2f7csm10284957wrs.101.2022.12.19.06.51.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 06:51:09 -0800 (PST) From: Andrew Burgess To: Tom Tromey via Gdb-patches , gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH 2/4] Don't erase empty indices in DWARF reader In-Reply-To: <20221215190759.2494095-3-tromey@adacore.com> References: <20221215190759.2494095-1-tromey@adacore.com> <20221215190759.2494095-3-tromey@adacore.com> Date: Mon, 19 Dec 2022 14:51:08 +0000 Message-ID: <878rj3zbtv.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tom Tromey via Gdb-patches writes: > The DWARF reader has some code to remove empty indices. However, I > think this code has been obsolete since some earlier changes to > parallel_for_each. This patch removes this code. Would NULL entries cause problems later in GDB? Would it be worth replacing this code with an assert that there are no NULL entries? Or would an attempt to create a NULL entry trigger an assert/error elsewhere? Or maybe the cost of iterating over the list is what you want to remove here? In which case, could we guard an assert in '#ifdef DEVELOPER'? Thanks, Andrew > --- > gdb/dwarf2/read.c | 10 ---------- > 1 file changed, 10 deletions(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 032e20af93a..a3f4ef351eb 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -7170,16 +7170,6 @@ dwarf2_build_psymtabs_hard (dwarf2_per_objfile *per_objfile) > print_tu_stats (per_objfile); > > indexes.push_back (index_storage.release ()); > - /* Remove any NULL entries. This might happen if parallel-for > - decides to throttle the number of threads that were used. */ > - indexes.erase > - (std::remove_if (indexes.begin (), > - indexes.end (), > - [] (const std::unique_ptr &entry) > - { > - return entry == nullptr; > - }), > - indexes.end ()); > indexes.shrink_to_fit (); > > cooked_index_vector *vec = new cooked_index_vector (std::move (indexes)); > -- > 2.34.3