From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id B1432385841C for ; Thu, 19 Oct 2023 22:06:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1432385841C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B1432385841C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697753219; cv=none; b=biWxDxxJ2zwzdqU1fGrKNAnxdrXtxLtfUJcIfruE73s4+qLZFfd3+lZzWy2VL6oMh1N45A4SBLtIBK69GnSSpKvqNkhIxFEqHyNOVU1tNz5gJXKXzBEb/vSoHrKXJqpVH7XuQAO6xhQDenBKKizdq57RZC/ghOeK57+PoLY8kmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697753219; c=relaxed/simple; bh=yKRifxHaDXy2KxJSKB8dnaGQb/3fiKcatDYtjni7crw=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Tr4D6MOpAQ3141RPKiVClofkyau682s8Kiz6TLa/U1TPVhGgqwJ6/ARV5iPZaeE5JS9EFcCncvbJND9CcGMsNm1q9FUQ8gJb6se58yxIE+8e9zGu9q3LTrDbXp+r+voEuWHH4BM7FtCu4LMbqKRjPp7YR5p5PYqYf9YQ4jf8STM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id B5B5C302FDCA; Fri, 20 Oct 2023 00:06:55 +0200 (CEST) Date: Fri, 20 Oct 2023 00:06:55 +0200 From: Mark Wielaard To: Heather McIntyre Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH 11/16] libdw: Add locking around __libdw_dieabbrev for dwarf_hasattr Message-ID: <20231019220655.GE14066@gnu.wildebeest.org> References: <301fac87e83ebbbd677750579ae9a3429b461bdf.camel@klomp.org> <20231010134300.53830-1-mark@klomp.org> <20231010134300.53830-11-mark@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3028.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Heather, On Tue, Oct 17, 2023 at 02:57:39PM -0500, Heather McIntyre wrote: > I see now that this is incomplete considering the other places that also > call this function. I do agree that global locking may be heavy if 1) > implemented in all of these locations, or 2) implemented directly in > __libdw_dieabbrev. We could use atomics here directly in __libdw_dieabbrev. > I have given this a try and it is currently passing all tests, including > the new ones I added for data race detection. > > I know you mentioned that taking any pthread lock at all might be a big > overhead, but since I implemented a per dwarf struct lock, would using that > be a possibility? Assuming multiple calls to __libdw_dieabbrev will be > working on different dwarf objects. I have been thinking about this issue and I think we made a mistake in designing how a Dwarf_Die is lazy initialized. The abbrev field of a Dwarf_Die is only set when needed by calling __libdw_dieabbrev, which means we need some kind of locking or atomic swapping whenever we try to use that field. I assume the idea originally was that calling __libdw_dieabbrev is fairly "heavy" (it is, potentially reading the whole .debug_abbrev for the CU). So we try to postpone it till it is really needed. But in practice it is always needed. Without the abbrev field set you can just call dwarf_dieoffset, dwarf_cuoffset, dwarf_diecu and dwarf_getabbrev. In theory you could avoid adding the abbrev for the initial CU DIE for a Dwarf_CU when you are iterating over all CUs and know you don't need the CU without inspecting the initial CU DIE. But the Dwarf_Abbrev_Hash for the Dwarf_CU will already be initialized. And normally the abbrev for the first DIE will also be the first abbrev, so searching for it should be really quick. So I think setting the Dwarf_Die abbrev field lazy is not really helpful and makes the code needlessly complex. If we set the abbrev field when a Dwarf_Die is created we can simplify the code and don't need all this locking when we just want to access the field. This of course is still a lot of coding, we'll have to check every place that initializes a new Dwarf_Die. Which will have to call __libdw_dieabbrev directly. But I think that will not need any extra locking because the Dwarf_Abbrev_Hash used is already thread-safe (it was written by Srđan Milaković also from Rice University). What do you think? Cheers, Mark