From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qc4AONvVDWoXcgoAWB0awg (envelope-from ) for ; Wed, 20 May 2026 11:40:11 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=U9YHJRXn; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E0BA41E098; Wed, 20 May 2026 11:40:11 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 148331E024 for ; Wed, 20 May 2026 11:40:11 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2DF734BB58F4 for ; Wed, 20 May 2026 15:40:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DF734BB58F4 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=U9YHJRXn Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id D97AD4BB5923 for ; Wed, 20 May 2026 15:39:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D97AD4BB5923 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D97AD4BB5923 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779291545; cv=none; b=XM7nrPxWnJsG3NyIYyyHWEL8MXH1AqEGfipbuBgjykqT23Zl1iBVYXg/5ofiRpOqSVoN/rxiULjgA7UiySEz6jAcLCwgaaHOTa+Ok6a3vdnuzCDV8fRcau31IxnWzG3n3JKRVK+RJ2DPyE6LPLVnw8Un6p6oqndMMc9foFBJWMw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779291545; c=relaxed/simple; bh=i9lgYrNdyqAd6Atlm4aNE9uUQVOe8NxD43nW/4/5G58=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=kWSnq0obZ/X9lhxjnz4ntIEIld4mrWYO3MK4JYlALRvq6BO6b+tnAPSMLvteGFI9rPzllirfYDWYB9+o6iRjpVpCBplcnuBzYN6voQ506j3kJdAiudR9jbzcOsJZpDz6kqn6d9iQh3lwVbg23S+gdcAoFUWYupQl0MubbdxLAZQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=U9YHJRXn DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D97AD4BB5923 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 64KFcwj2121875 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 May 2026 11:39:02 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 64KFcwj2121875 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1779291543; bh=NsXDixWJMIEOuwenklq7EpyksVifhfrBJIz7pHM9wyY=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=U9YHJRXndZrspsS7WprQ61a9aODjqvvDZl0GVZ6LFjFj7Vj+IL/VV7m8qyE15oZKg CXF4U8DCpd3n9MJDcOQdX2slO/FgDbw9A5XLiV84jjSWcbFwsR3egHCnJjI5bFT55r R9IW6NWWU8eBmk0kYBjvAzHt7Y4tQ8O5rxfF/DWYvyG+XBhJJXv1VtFuZtk3LmQ9a7 gaFOFP2Ez/yQvc+PMFWm0QMJjEoYdLyRplub/qKalRQgUyeeoQJsTP6ZKH8Wh/WYs2 GPIz7pAIuzxefplGmTfT5Zx2sILE6nzYbV5HTcySr9tSCz29Q+2KMJKvsUuai3rGmr UJ36FFPuQrVng== Received: by simark.ca (Postfix) id 1EEDC1E024; Wed, 20 May 2026 11:38:57 -0400 (EDT) Message-ID: <23229f43-fbb7-4138-a4ab-26946c124744@polymtl.ca> Date: Wed, 20 May 2026 11:38:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/dwarf: fix order of operations when reading .debug_names To: Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org References: <20260519200917.342813-1-simon.marchi@efficios.com> <87zf1u9kok.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87zf1u9kok.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 20 May 2026 15:38:58 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 2026-05-20 11:15, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> - calls to the build_and_check_* functions, which do some lookups in > Simon> the all_units vector, requiring it to be sorted (oops) > > I wonder if either there's some way to assert that the vector must be > sorted on entry, or if there's a way to have a self-sorting data type > here, rendering this kind of bug impossible. assert: in dwarf2_find_unit, we could check that the vector is sorted, but that would replicate the check done by -D_GLIBCXX_DEBUG. I'm not sure we want to pay this price for every dwarf2_find_unit call in production binaries. Alternatively, we could maintain a flag that says "is all_units currently sorted", clear that flag when doing any modification to the vector, and set it in the sort_all_units method. All modifications to the vector should be done through methods to ensure the flag gets cleared. I think that would be cheap enough to implement, I'll give it a try. self-sorting data type: we could insert the new units at the right place from the start, but that would be less efficient, because that would be akin to an insertion sort. It's more efficient to do one sort at the end. We could perhaps use std::set, but there is also the case in fill_in_sig_entry_from_dwo_file, when the section of a unit becomes known at a later time. At this point, the key for the unit would change, so we would still need to remove it and reinsert it in the set. I don't see a way to enforce that automatically. > Anyway I think this is ok. > Approved-By: Tom Tromey Thanks, I'll push it and work on a patch to add the assert. Simon