From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nOB4MGYBhmnAEywAWB0awg (envelope-from ) for ; Fri, 06 Feb 2026 09:57:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770389862; bh=6J2Nq7O5rOELHfJdIQ6HvZdk7+9vkL+3hAk7tw59QXU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=XYu8NcU96cQvkU2Te8PV2yLCDYIOViRNqtVCGiIYwBxMORLOGXXyzp1erV93fnPcC /5n3cAOINtjhRtOo4b3il7n52HTe35iJFwxDT28YWP70MVwLugnJWWDa50zzzKuSg5 hwCrRmo4UMR1Bx3Xosq1OLbSSpK6mAs3hR+pcVcs= Received: by simark.ca (Postfix, from userid 112) id A71A51E0BA; Fri, 06 Feb 2026 09:57:42 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.6 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,RDNS_NONE autolearn=no 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=F0bLT9LO; dkim-atps=neutral Received: from vm01.sourceware.org (unknown [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 E0C731E08D for ; Fri, 06 Feb 2026 09:57:41 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 69AA74423FBA for ; Fri, 6 Feb 2026 14:57:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69AA74423FBA 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=F0bLT9LO Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 3DE464423F95 for ; Fri, 6 Feb 2026 14:56:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3DE464423F95 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 3DE464423F95 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=1770389791; cv=none; b=kEcdyUp3hVRrpS7zaWs/Ygv5OhJ/P/UODcL63esMy0dHd85/ogsqV3UCfZgz15NN5PT0J1V/s4GXcy5IZ60HyhoNNBPfD7BOL0tlp6SbF/KROyfPI588bU2MZBLFLJyQXNG8JdZyt1jK7WCOB8DUn8kI4lzyb1YICWEnxEqqD2g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770389791; c=relaxed/simple; bh=6J2Nq7O5rOELHfJdIQ6HvZdk7+9vkL+3hAk7tw59QXU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=d13a318ClWoL9IMX6O9WpF9m/gqz3ljrc1j0KV8Thpi3sLITXBUtMXGolU4keeT3vFl8qjB9DqslHI8XPrZD0ULU3klX73yyFYidh3JMOlzirozo7vn4gs3DBDrAGUC7FXUPmswzy8uQ0OmUP9Em0j8a+y59RdtCpxiloOuv0TM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3DE464423F95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770389790; bh=6J2Nq7O5rOELHfJdIQ6HvZdk7+9vkL+3hAk7tw59QXU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=F0bLT9LO5Ou9W9KWodD8kpaaV8uKEQPHIzL4YGI9thepjppsHkV72bjZqEbKlGgM0 fTr3hOARhAgLRbtIEscEMFgDiGRXyWugt6OXuebN2c2pw8cZvRyF53bLIDGCohuZft aqTPFd4D+pdBG2wNXehKKq4t/gj7PYbmmJdioszQ= Received: by simark.ca (Postfix) id 204021E08D; Fri, 06 Feb 2026 09:56:30 -0500 (EST) Message-ID: <068592e1-0817-4ef4-9605-da51ffdfb495@simark.ca> Date: Fri, 6 Feb 2026 09:56:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: make gdb.dwarf2/dw2-empty-inline-ranges.exp work when ASLR can't be disabled To: Andrew Burgess , Simon Marchi , gdb-patches@sourceware.org Cc: Luis References: <20260205204257.422150-1-simon.marchi@efficios.com> <87bji2dkng.fsf@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87bji2dkng.fsf@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 2026-02-06 09:14, Andrew Burgess wrote: > Simon Marchi writes: > >> A colleague that goes by the name "Luis Machado" reported a failure when >> running gdb.dwarf2/dw2-empty-inline-ranges.exp. After investigation, we >> found that the conditions for the test to fail are: >> >> - running in an environment where GDB can't disable address space >> randomization (such as in a container where that capability is >> removed) >> >> - a toolchain generating position-independent executables >> >> The test does a first run to grab the addresses of a few labels defined >> in the source file. It then crafts the DWARF using these addresses. >> And then it does a second run for the actual test stuff. >> >> When the executable is PIE and ASLR is active, then the addresses in >> both runs don't agree, which the test doesn't expect. >> >> It is possible to emulate the failure by inserting some: >> >> gdb_test_no_output "set disable-randomization off" >> >> after both "prepare_for_testing" calls. The (first) failure then >> manifests as: >> >> FAIL: gdb.dwarf2/dw2-empty-inline-ranges.exp: dwarf_version=4: empty_loc=start: entry_pc_type=empty: stopped at entry-pc >> >> This test compares the expected stop PC "entry_pc" with the actual stop >> PC "pc". In my example run, they were indeed different: >> >> pc = 0x5603ec67a159 >> entry_pc = 0x55baba6a9159 >> >> The simplest way to fix this, which this patch implements, is to use >> "nopie" when building the binaries. I don't think this affects the >> effectiveness of the test. >> >> Also, in the first run, it is longer necessary to run the inferior >> before grabbing the addresses, they are going to be the same with a >> non-PIE executable. So remove that. > > Thanks for fixing this. LGTM. > > Approved-By: Andrew Burgess > > > Thanks, > Andrew > Thanks, pushed. I actually added a small comment in the test file to explain why we use nopie. Simon