From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OfYNAOsAhWnjOioAWB0awg (envelope-from ) for ; Thu, 05 Feb 2026 15:43:23 -0500 Received: by simark.ca (Postfix, from userid 112) id ECE711E0BA; Thu, 05 Feb 2026 15:43:22 -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.5 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 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 3431B1E08D for ; Thu, 05 Feb 2026 15:43:22 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id C88414C91752 for ; Thu, 5 Feb 2026 20:43:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C88414C91752 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 6E3AA4BBC0A5 for ; Thu, 5 Feb 2026 20:42:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6E3AA4BBC0A5 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=efficios.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6E3AA4BBC0A5 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=1770324179; cv=none; b=vFvJ367nA8KLPlF4ebv7dh+t2d5pNMb1Afh7bsFgzLWNx5wXNvsbTb49OgVctbLbYUAqopt6iHeWOrUD6qubyuLsjpHIriBYE/4LRz8VDJFG/+HZpaIt9BEBrb2vIfVwbTtcOFthBhWc2BT/RthMHFHP2MmEKEciQ99EWae7QQ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770324179; c=relaxed/simple; bh=YB1O6KnglVPCH9rzmld4b03gYctSglQ0OiLoo6wqLE8=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=P3Ajj7JhbIOyWJcue9p/quiOsiFKQmb+jhQhGOfJNG/Xt7/0QnTeF/6sUnIWaGn/I5hAPqiIqFMy0Xi51kXXoJHF3frSCtb1I/ZsmvE5U7Rwu5LJQATcNQt1D2NuuEznByKdfHvWObwAQHmyx/cdxcW5SkHwJwz1HkoumKwc8Ik= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E3AA4BBC0A5 Received: by simark.ca (Postfix) id CDD0F1E08D; Thu, 05 Feb 2026 15:42:58 -0500 (EST) From: Simon Marchi To: gdb-patches@sourceware.org Cc: Luis , Simon Marchi Subject: [PATCH] gdb/testsuite: make gdb.dwarf2/dw2-empty-inline-ranges.exp work when ASLR can't be disabled Date: Thu, 5 Feb 2026 15:42:50 -0500 Message-ID: <20260205204257.422150-1-simon.marchi@efficios.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 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. Change-Id: I3e9b1c056c30a49e01e1a1d3bf28f7e0e409f3c9 --- gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp b/gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp index ef75f642ac7d..16cd6ecbcfde 100644 --- a/gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp +++ b/gdb/testsuite/gdb.dwarf2/dw2-empty-inline-ranges.exp @@ -56,11 +56,7 @@ get_func_info main # Compile the source file and load the executable into GDB so we can # extract some addresses needed for creating the DWARF. if { [prepare_for_testing "failed to prepare" ${testfile} \ - [list ${srcfile}]] } { - return -1 -} - -if {![runto_main]} { + [list ${srcfile}] {debug nopie}] } { return -1 } @@ -187,7 +183,7 @@ proc run_test { dwarf_version empty_loc entry_pc_type } { write_asm_file $asm_file $dwarf_version $ranges $entry_pc_label if {[prepare_for_testing "failed to prepare" $this_testfile \ - [list $::srcfile $asm_file] {nodebug}]} { + [list $::srcfile $asm_file] {nodebug nopie}]} { return } base-commit: 458328833813d78831a0b1a24a0984db91c95fc0 -- 2.53.0