From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FbE5HfnNP2gdUAAAWB0awg (envelope-from ) for ; Wed, 04 Jun 2025 00:39:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749011961; bh=cqB503EwmURS1ZnlPVV31fwn3lhp9hfgSAvDmIXVym4=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Eb86tKT/fSfOMrgfHUGfiWmV/SBf6eE9tLjk6r0YVJFlyCWcbdjiuIL/yplX+l/fU 7fPpDizPtjRAvwnqpXdfa2B9dufk9C3306riCPL3OkS24FWItzZd7CgA4NG1vkgn5d JKs9HAEU7R9veauE8lcd9xjmbXFY4RfXhZdZMvB0= Received: by simark.ca (Postfix, from userid 112) id 649F31E102; Wed, 4 Jun 2025 00:39:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 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,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=csSwgq+e; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=toJBB9DB; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 D181B1E089 for ; Wed, 4 Jun 2025 00:39:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6D5153858401 for ; Wed, 4 Jun 2025 04:39:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6D5153858401 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=csSwgq+e; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=toJBB9DB Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id F0D7F3858D3C for ; Wed, 4 Jun 2025 04:38:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0D7F3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F0D7F3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749011931; cv=none; b=LJV/HT7lWEjBX1U0Y1qlX6aQEgUa3s7qDj3OlJU7neYCROy8IlUiqQqc0PGylz8AEiOe0iCzPXBcYrHVeUzeiKURU66Yn2vD9grQT7Jr2tu01S6iClidOuvrjuf/NAdZCWzdKuMAbNpPjPBAv/8Uo1Hq4/68KJiVd4M5BOvHj+k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749011931; c=relaxed/simple; bh=cqB503EwmURS1ZnlPVV31fwn3lhp9hfgSAvDmIXVym4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=G5CEVjZ0dU02ylSpUSliDPJMMff/QnesNNNyi33X9cWPoE6YQMMMGCpsfUK7mLs6zTRccgUYOFKXEwYY8ekrD7BEqHvs9mNxe980gk1kWRlLmLLRBrYksm+TatcRg8FM5r/ZP7MIKxitUQX+HGz8cXnOocBSVRDTEyuKAyw2LGY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0D7F3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749011930; bh=cqB503EwmURS1ZnlPVV31fwn3lhp9hfgSAvDmIXVym4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=csSwgq+e0Om7Dw0JNZyrQ3Wki5geetpQkqMUruoWM6EFtC7aTS+ZEgP0YJnUdUjXY hGLij6H6/3nxXarWi137mc+tYOZyUhgK7LokkAi9RdqhbnZiWvjSo9zFaOgF4d3nNM ufmifie4cGOJF37tzfU15+NIzj6MtXeacGQYnGRU= Received: by simark.ca (Postfix, from userid 112) id 793AE1E11E; Wed, 4 Jun 2025 00:38:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749011929; bh=cqB503EwmURS1ZnlPVV31fwn3lhp9hfgSAvDmIXVym4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=toJBB9DBj4TlrU8FHqmtXhbvaKxRbrX5cH9KPn8r4TMb2vN7AdrflV9a10ioZaW29 NsBUPwGYUqBM9uaLJaKSknLaXTqUsfBJ0g8nDH+g56r3jNbyzPPqwyoWw77SeoXpj9 SgL0/G9eAM4yRXICvwR7zaafABorZlNkRtM1YUTA= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 165A51E089; Wed, 4 Jun 2025 00:38:49 -0400 (EDT) Message-ID: <0cd026ed-3be2-486b-8f09-effe23f30562@simark.ca> Date: Wed, 4 Jun 2025 00:38:48 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/solib: pass lm_info, original_name and name to solib constructor To: Guinevere Larsen , Simon Marchi , gdb-patches@sourceware.org References: <20250603153257.55235-1-simon.marchi@efficios.com> <0bc50478-6756-4825-8080-031e3aef864a@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <0bc50478-6756-4825-8080-031e3aef864a@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 2025-06-03 19:07, Guinevere Larsen wrote: >> + sos.emplace_back (std::move (info), info->name, info->name); > This is a bad idea. I double checked with c++ folk and while no > compilers warn about this, if the compiler evaluates things right to > left (like gcc) this works, but if they evaluate left to right (like > clang), then info->name will be de-referencing null and segfault. This > might also depend on ABI, but the end result is the same: fragile at > best. we'll need something that saves or moves info->name to pass it > to the emplace_back constructor Wow, good catch, thanks. Actually, with C++17, I think the order of evaluation has been specified from left to right. So, I think it should crash regardless of the compiler. I don't think that the testsuite exercises that code though on Linux. A more long-term fix would be to move the name out of lm_info_target (it doesn't belong there anyway). But for now I'll change it like so in my patch: for (lm_info_target_up &info : library_list) { /* Move NAME to a local variable to avoid reading INFO->NAME after having moved info. */ std::string name = std::move (info->name); sos.emplace_back (std::move (info), name, name); } It seems to be the only occurrence of this problem in the patch. Simon