Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Bratislav Filipovic <bfilipov@amd.com>
To: <gdb-patches@sourceware.org>
Cc: Bratislav Filipovic <bfilipov@amd.com>
Subject: [PATCH] gdb/testsuite: fix dw2-entry-pc.exp with ASLR
Date: Tue, 14 Apr 2026 16:48:03 +0000	[thread overview]
Message-ID: <20260414164814.564571-1-bfilipov@amd.com> (raw)

Following Simon Marchi's fix for dw2-empty-inline-ranges.exp [1], this
test exhibits the same failure pattern when running in an environment
where GDB can't disable address space randomization (such as in a
container where that capability is removed) with a toolchain generating
position-independent executables.

The test does a first run to grab addresses of labels and function
boundaries (foo_middle, foo_start, foo_end, and range labels).  It then
crafts DWARF using these addresses across multiple test iterations.
When the executable is PIE and ASLR is active, the addresses in each
subsequent run don't match the addresses from the initial run.

The failure manifests in the 'maint info blocks' output comparisons,
where the expected addresses (from the first run) don't match the
actual addresses in the test runs.

The simplest fix, following Simon's approach, is to use "nopie" when
building the binaries.  This doesn't affect the effectiveness of the
test, which is exercising different ways DW_AT_entry_pc can be
expressed in DWARF.

Also, with a non-PIE executable, it is no longer necessary to run the
inferior before grabbing the addresses in the initial run, as they are
stable.  So remove that runto_main call.

[1] https://inbox.sourceware.org/gdb-patches/20260205204257.422150-1-simon.marchi@efficios.com/
---
 gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp
index 441aa0fde1d..f7cc7f7c067 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-pc.exp
@@ -28,11 +28,7 @@ standard_testfile
 get_func_info foo
 
 if { [prepare_for_testing "failed to prepare" ${testfile} \
-	  [list ${srcfile}]] } {
-    return -1
-}
-
-if {![runto_main]} {
+	  [list ${srcfile}] {debug nopie}]} {
     return -1
 }
 
@@ -83,7 +79,7 @@ proc get_next_suffix {} {
 
 proc build_and_runto_main { suffix asm_file } {
     if {[prepare_for_testing "failed to prepare" "${::testfile}-${suffix}" \
-	     [list $::srcfile $asm_file] {nodebug}]} {
+	     [list $::srcfile $asm_file] {nodebug nopie}]} {
 	return false
     }
 
-- 
2.43.0


             reply	other threads:[~2026-04-14 16:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 16:48 Bratislav Filipovic [this message]
2026-04-14 18:08 ` Simon Marchi
2026-04-15 10:32   ` Filipovic, Bratislav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260414164814.564571-1-bfilipov@amd.com \
    --to=bfilipov@amd.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox