From: Simon Marchi <simon.marchi@efficios.com>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: [PATCH 6/6] gdb/linux-tdep: ignore non-Linux threads in get_ptid_for_slash_proc
Date: Fri, 16 Oct 2026 01:20:11 -0400 [thread overview]
Message-ID: <20261016052100.1386999-7-simon.marchi@efficios.com> (raw)
In-Reply-To: <20261016052100.1386999-1-simon.marchi@efficios.com>
Commit 2f4e6ea8c05 ("gdb: use the selected thread's LWP ID when reading
Linux procfs files") made get_ptid_for_slash_proc prefer the selected
thread. It does not consider that the inferior's thread list may
contain threads that are not Linux threads, such as AMD GPU waves. The
amd-dbgapi target numbers waves like this:
(pid, 1, wave_id)
where pid is the host process' pid and wave_id a non-zero number handed
out by the amd-dbgapi library. If a GPU wave is selected,
get_ptid_for_slash_proc returns its ptid, and GDB attempts to read files
under "/proc/1/", which is bad.
This happens when running "gcore" while a GPU wave is selected. As a
result, a bunch of information coming for /proc is missing from the core
file (unless you are running GDB as root, in which case it successfully
reads the information for the init process, but then it's the wrong
info).
Fix this by making get_ptid_for_slash_proc aware that non-Linux threads
may exist, using the is_linux_thread function added by a previous patch.
The logic is now to use the selected thread if it has not exited and it
is a Linux thread. Otherwise, look for any non-exited Linux thread.
Extend gdb.rocm/gcore-host.exp to also generate a core file while a wave is
selected. The test also covers the fix from the previous patch, which makes the
NT_AUXV note present in that case. To verify it:
- Check that "info auxv" shows the auxiliary vector when the core file is
loaded.
- Run the program with a long argument, and check that GDB shows the full
command line when loading the core file. GDB reads the command line from
memory, starting at the address given by AT_EXECFN in the auxiliary vector.
Without the auxiliary vector, it falls back to the command line saved in the
NT_PRPSINFO note, which is truncated to 80 characters.
- Build the test program as a PIE, since loading the core file of a PIE
requires the auxiliary vector to find where the executable and the shared
libraries are loaded, and check that "info sharedlibrary" lists the HIP
runtime library.
Change-Id: I3582344e25fa632bb21d77b38bd3b755c6cc644b
---
gdb/linux-tdep.c | 28 ++++++++++++++++----------
gdb/testsuite/gdb.rocm/gcore-host.exp | 29 ++++++++++++++++++++++++---
2 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 3491c63c017a..d42195c4ebe7 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -479,23 +479,29 @@ is_linux_thread (const thread_info &thread)
/* Return the ptid of a thread of the current inferior whose lwp id can be
used to build "/proc/<lwp>" paths.
- Through any_non_exited_thread_of_inferior, this function prefers the
- currently selected thread, if it has not exited. For most information in
- /proc, it does not matter which thread of a process we pick. But a few
- entries (like stat counters) are thread-specific. This allows the user
- to focus a particular thread and get specific information about that
- thread.
+ This function prefers the currently selected thread, if it has not exited
+ and is a Linux thread. For most information in /proc, it does not matter
+ which thread of a process we pick. But a few entries (like stat counters)
+ are thread-specific. This allows the user to focus a particular thread
+ and get specific information about that thread.
- Throw an error if the inferior has no thread that GDB believes is
+ Throw an error if the inferior has no Linux thread that GDB believes is
alive. */
static ptid_t
get_ptid_for_slash_proc ()
{
- if (thread_info *thread
- = any_non_exited_thread_of_inferior (current_inferior ());
- thread != nullptr)
- return thread->ptid;
+ if (inferior_ptid != null_ptid)
+ {
+ thread_info *thread = inferior_thread ();
+
+ if (thread->state () != THREAD_EXITED && is_linux_thread (*thread))
+ return thread->ptid;
+ }
+
+ for (thread_info &thread : current_inferior ()->non_exited_threads ())
+ if (is_linux_thread (thread))
+ return thread.ptid;
error (_("Could not find a non-exited thread to read /proc from."));
}
diff --git a/gdb/testsuite/gdb.rocm/gcore-host.exp b/gdb/testsuite/gdb.rocm/gcore-host.exp
index 80bf60e4e9f5..867f803f4381 100644
--- a/gdb/testsuite/gdb.rocm/gcore-host.exp
+++ b/gdb/testsuite/gdb.rocm/gcore-host.exp
@@ -23,7 +23,10 @@ standard_testfile .cpp
require allow_hip_tests
-if {[build_executable "failed to prepare" $testfile $srcfile {debug hip}]} {
+# Build a position-independent executable. Loading the core file of a PIE
+# requires the auxiliary vector (NT_AUXV note) to find where the executable
+# is loaded.
+if {[build_executable "failed to prepare" $testfile $srcfile {debug hip pie}]} {
return
}
@@ -34,6 +37,15 @@ if {[build_executable "failed to prepare" $testfile $srcfile {debug hip}]} {
proc do_test { selected_thread } {
clean_restart $::testfile
+ # To verify that the auxiliary vector was properly written to the core,
+ # pass a long argument to the program, to make the command line longer than
+ # what the NT_PRPSINFO note can hold (80 characters). When loading the
+ # core file, GDB uses the auxiliary vector to read the full command line
+ # from memory. Without the auxiliary vector, it falls back to the
+ # truncated command line from the NT_PRPSINFO note.
+ set long_arg [string repeat x 100]
+ gdb_test_no_output "set args $long_arg"
+
set corefile [standard_output_file $::testfile.$selected_thread.core]
with_rocm_gpu_lock {
@@ -75,10 +87,21 @@ proc do_test { selected_thread } {
clean_restart $::testfile
+ # Check that GDB shows the full command line, which requires the NT_AUXV
+ # note to be present and correct.
gdb_test "core-file $corefile" \
- "Core was generated by `[string_to_regexp $::binfile]'\\..*" \
+ "Core was generated by `[string_to_regexp "$::binfile $long_arg"]'\\..*" \
"load corefile"
+ # Check that the core file contains the auxiliary vector (NT_AUXV note).
+ gdb_test "info auxv" \
+ "AT_ENTRY +Entry point of program +$::hex\r\n.*AT_NULL +End of vector +0x0" \
+ "core file auxv"
+
+ # Check that GDB finds the shared libraries loaded by the program.
+ gdb_test "info sharedlibrary" "/libamdhip64\\.so.*" \
+ "core file shared libraries"
+
# The core file is expected to contain all the host threads, and nothing
# else.
set num_core_threads 0
@@ -97,6 +120,6 @@ proc do_test { selected_thread } {
}
}
-foreach_with_prefix selected_thread { host } {
+foreach_with_prefix selected_thread { host wave } {
do_test $selected_thread
}
--
2.56.0
prev parent reply other threads:[~2026-10-16 5:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 5:20 [PATCH 0/6] Fix generating core files when GPU waves are present Simon Marchi
2026-10-16 5:20 ` [PATCH 1/6] gdb/testsuite: make with_rocm_gpu_lock transparent to return Simon Marchi
2026-10-16 5:20 ` [PATCH 2/6] gdb/corefile: handle no signalled thread when writing NT_GDB_TDESC Simon Marchi
2026-10-16 5:20 ` [PATCH 3/6] gdb/amd-dbgapi: handle regno == -1 in fetch_registers and store_registers Simon Marchi
2026-10-16 5:20 ` [PATCH 4/6] gdb/linux-tdep: don't write core file notes for non-Linux threads Simon Marchi
2026-10-16 5:20 ` [PATCH 5/6] gdb/amd-dbgapi: defer TARGET_OBJECT_AUXV xfers to the beneath target Simon Marchi
2026-10-16 5:20 ` Simon Marchi [this message]
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=20261016052100.1386999-7-simon.marchi@efficios.com \
--to=simon.marchi@efficios.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