From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 04E8F3858D1E for ; Wed, 2 Aug 2023 19:39:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04E8F3858D1E 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-il1-x133.google.com with SMTP id e9e14a558f8ab-34942e1bfadso717355ab.1 for ; Wed, 02 Aug 2023 12:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1691005197; x=1691609997; 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=hp5R2tNgbiPjI7JRdPqgZD2lh2SLdyIz1ejzK1O9TRY=; b=kCPVKVoVTqGUUKLeTjff4msmiHPrG5jx6yrm9BizSPBp+FCV4yW0kIes7GNkr5I6Ls YaMKHj7cOnKoE0wsG8ucFh/cvt6W4dY6BmEdSUVLmkq/kjd5XBfF9rwROUJXhXap5Ijs WHRZZyek+/WzaxX1pKwN0+vj1Z/EX6BPursB0fPX1XOYueRhaZeE2XcYqFw+hE0k2jlZ xF8pRayl1wWulYvvIJd/gnJnyIyqFexhiyzQ/Vo3GwDqyhqvro3xNKql9budNRiCFpzd DzE6J7mE6P0HePBD6oZe5JgY1VGQykjGkNmKymjaKxCskfL7KQ1Hwb6i0kcYoBejoN4A RHLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691005197; x=1691609997; 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=hp5R2tNgbiPjI7JRdPqgZD2lh2SLdyIz1ejzK1O9TRY=; b=bhH9LwRQptBPcdMBb/gHEXPo607w03KdPDk38UfTzlBZpVss/sCNfzVv+TFjS+hkkp 5nQDq8DUGL2AIe2PQ7iO1VOLehVblgdxxYB+FXidOKbYxpSoHlYf7C6DFaWrhL+JYJ3i ouGH3Epib9azD2Fz8Vwt3jPlmgSt7ZVb5SGTuPd+5dU9B0TvWQVt+PQA9UZrrI4bkvdx xfXqijcQGHkSclDtmQRrSXIDVIo0w/4nDI6THkLY00DWkhfQWZMbR8n9ruHvbWAZv802 o4/8O96ln9dVP3Jdr4TpBrX8+jVAQS0eFT0RVzFlkWcDdKG+hznfE3T8s/zkPHID6nxU oOcg== X-Gm-Message-State: ABy/qLb/NPzsTFqnY/Xlv6mnoC5mQ3sTlQM5anfPdeZAJ5hstMwPvJJN Ot7NH71r5x1psPd7EydSnV9tyNRAoQfAFtANYky1uA== X-Google-Smtp-Source: APBJJlGPhbzhCZqT+bFPId2M5FhGJnW1zj6iaUc6VwUK9zmLkzDPuFdv9SC6fk/y9Jxl+wNPwo3uXw== X-Received: by 2002:a05:6e02:dd1:b0:348:999b:2c44 with SMTP id l17-20020a056e020dd100b00348999b2c44mr16132724ilj.26.1691005197277; Wed, 02 Aug 2023 12:39:57 -0700 (PDT) Received: from murgatroyd (75-166-148-59.hlrn.qwest.net. [75.166.148.59]) by smtp.gmail.com with ESMTPSA id r4-20020a92c504000000b0034294982b83sm4677839ilg.69.2023.08.02.12.39.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Aug 2023 12:39:56 -0700 (PDT) From: Tom Tromey To: Tom de Vries via Gdb-patches Cc: Tom de Vries Subject: Re: [PATCH v2 5/6] [gdb/symtab] Fix data race on dwarf2_per_cu_data::{m_header_read_in, is_debug_type} References: <20230802095305.3668-1-tdevries@suse.de> <20230802095305.3668-6-tdevries@suse.de> X-Attribution: Tom Date: Wed, 02 Aug 2023 13:39:56 -0600 In-Reply-To: <20230802095305.3668-6-tdevries@suse.de> (Tom de Vries via Gdb-patches's message of "Wed, 2 Aug 2023 11:53:04 +0200") Message-ID: <87bkfpdyib.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.1 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,T_SCC_BODY_TEXT_LINE 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" == Tom de Vries via Gdb-patches writes: Tom> The race is between: Tom> - a worker thread writing the index cache, and in the process reading Tom> dwarf2_per_cu_data::is_debug_type, and Tom> - the main thread writing to dwarf2_per_cu_data::m_header_read_in. Tom> The two bitfields dwarf2_per_cu_data::m_header_read_in and Tom> dwarf2_per_cu_data::is_debug_type share the same bitfield container. Tom> Fix this by making dwarf2_per_cu_data::m_header_read_in a packed. Thanks. This is ok. Approved-By: Tom Tromey FWIW I once tried to clean up the madness surrounding m_header_read_in and CU header reading in general. Unfortunately I did not succeed... I don't recall why but I think with DWO the header might have to be from the DWO. This is all kind of lame, because when doing the initial cooked index scan, the headers have to be read, and so it seems like the dwarf2_per_cu_data could be "more read-only" after that. Tom