From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 2E3843858D28 for ; Mon, 19 Dec 2022 17:09:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E3843858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-io1-xd32.google.com with SMTP id r72so5011945iod.5 for ; Mon, 19 Dec 2022 09:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=h4lQ7KJcfnKJA0rMg8J7+Yv8TOrNYWQAsRFaHDrVSpE=; b=G05pnfGaQNv5jKb1Uz3g1w0uDpteTMGcBryadnISXxGP5nfmRRMKM9+ZnYx+LpdLi0 ARUrSidjMB0eQKeDQP/zWCGyxj0T0pd1ruihxqVA3ofuGl8ffvTM2/ZXM0s/Q6JUtLKH 1Rw60P785erpirB+3CEfQ+LJNSJHgliIg/HpxB+vPd0Rg/9JALoQ4Af2R25+uzn6sI0b NPnUVH463WfwUkKQjFSKSXYrDgp5C+tKobs69LGIEZlb9T8ZJ7a6ZhcoGSUqhybCCtdB 9xwq5JcJ8oaV5oFAzJAlxN5IN8nlGMzxaaywjNrqJLFH/ofI+8goCkZyTbWkj/YsNKAA nBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h4lQ7KJcfnKJA0rMg8J7+Yv8TOrNYWQAsRFaHDrVSpE=; b=Y2oDsybkTjH7HiXySmpyCd5T+cVVdCyGjI/mZ+4B59jjDtOvw7+9+0v3rvjdXPsCvQ kZBQOlQ+K63oJtrtg8aeRAOQlNzQ7c2/b4R9Fn7ZfXzrpd7dIhWjDgICrVmMviIHbCyx nsfnM0QDnJUH6eJIs9E+3Nr7j72tVLQ0OsWXViM1gtoW/m31KNh8RfASl7gB8imHCHts RvhGMTRghQHszyQay4nJIVaHi76gjIg4P4Z9TzdAJ87cxm0V7lslNLZvQCG7Ko6cqzk/ GucobX6TpZikjiwyHXRoXvjyav7bLSm+Se+9mZ4RjJK1OVz44k5zd2pp02M1htGXWfWK VmeQ== X-Gm-Message-State: AFqh2kpEwXK4bQXl68stOrmXVi8D0Lve2aF5XfzT7EhofQED+W6iZNWr sWdjyEqMrUux3Xz7tLdIQWVQC7OJ5P1/fgEz X-Google-Smtp-Source: AMrXdXtSzZclAHtItNFrRGyQ+JGxc1rbDY5VV4PrItK8buCdbFT6sX4EWwCTxCJZrufVhC7KtVW63Q== X-Received: by 2002:a5d:9f10:0:b0:6ec:9bf1:3050 with SMTP id q16-20020a5d9f10000000b006ec9bf13050mr1265759iot.0.1671469747524; Mon, 19 Dec 2022 09:09:07 -0800 (PST) Received: from murgatroyd (97-122-76-186.hlrn.qwest.net. [97.122.76.186]) by smtp.gmail.com with ESMTPSA id q9-20020a0566022f0900b006cecd92164esm4089938iow.34.2022.12.19.09.09.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 09:09:07 -0800 (PST) From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey via Gdb-patches , Tom Tromey Subject: Re: [PATCH 2/4] Don't erase empty indices in DWARF reader References: <20221215190759.2494095-1-tromey@adacore.com> <20221215190759.2494095-3-tromey@adacore.com> <878rj3zbtv.fsf@redhat.com> X-Attribution: Tom Date: Mon, 19 Dec 2022 10:09:06 -0700 In-Reply-To: <878rj3zbtv.fsf@redhat.com> (Andrew Burgess's message of "Mon, 19 Dec 2022 14:51:08 +0000") Message-ID: <87tu1rl3rh.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: >>>>> "Andrew" == Andrew Burgess 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. Andrew> Would NULL entries cause problems later in GDB? Would it be worth Andrew> replacing this code with an assert that there are no NULL entries? Or Andrew> would an attempt to create a NULL entry trigger an assert/error Andrew> elsewhere? If it could happen, it would cause a crash when doing any kind of lookup, because cooked_index_vector iterates over the indices and calls methods on each one. Andrew> Or maybe the cost of iterating over the list is what you want to remove Andrew> here? In which case, could we guard an assert in '#ifdef DEVELOPER'? I don't think there's any performance issue, as the size of the array is normally just the number of cores on the user machine. It's more that this is a leftover and can't happen any more, due to the previous patch. It seems to me that the contract of parallel_for_each should be that, if it returns results (i.e., not void), then each entry in the result must be the result of actually calling the callback -- i.e., not some default. That said, it's also fine to drop this patch. Tom