Skip to content

[2026-06-16] Merge remote-tracking branch 'origin/master' into amd-staging#175

Merged
lancesix merged 37 commits into
amd-stagingfrom
users/lancesix/merge-2026-06-16
Jun 23, 2026
Merged

[2026-06-16] Merge remote-tracking branch 'origin/master' into amd-staging#175
lancesix merged 37 commits into
amd-stagingfrom
users/lancesix/merge-2026-06-16

Conversation

@lancesix

@lancesix lancesix commented Jun 16, 2026

Copy link
Copy Markdown
Collaborator

Handle conflicts introduced by recent upstream changes. Conflicting
upstream changes are:

  • c4aa08d gdb/amd-dbgapi-target: Move Linux code to amd-dbagapi-posix-hdep.c
  • f67ddc1 gdb/amd-dbgapi-target: Update xfer_partial to always use dbgapi
  • c04f1f5 gdb/testsuite: Add mechanism to compile Windows native programs on Cygwin
  • 2b5689d [gdb/contrib] Describe words in codespell-ignore-words.txt

Most changes were trivial. The main notable changes are in
gdb/testsuite/lib/gdb.exp, becauso of downstream change 27f8b77 "HIP
and set_unbuffered_mode_saved.o".

This merge commit also corrects one typo as codespell have been enabled
for the gdb directory by 664cc2d [pre-commit] "Include gdb in
codespell check".

lancesix and others added 30 commits June 12, 2026 14:36
The current amd-dbgapi-target.c file contains some code that is Linux
specific.  This patch extracts such code to host dependent files, so
they can be replaced for other host platforms.

The code in question is related to the event loop.  The way dbgapi
notifies GDB that there is a pending event is platform specific.  For
Linux (the only platform supported so far), this is done using a file
descriptor GDB can use in its main event loop.

This patch introduces an overall host-dependency infrastructure and
moves the Linux-specific code to amd-dbgapi-posix-hdep.c.  The "posix"
naming is because even though only Linux is supported, the code is
really plain POSIX code that would work on other POSIX platforms.
This also follows the existing posix-hdep.c nomenclature.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Id3d4b947176e5cfe91b0ab64376fca1a6a8c6fc9
This patch adds amd-dbgapi-mingw-hdep.c which provides the
implementations for all the host specific interactions with dbgapi on
MinGW.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ie244f2606b1e0af8f85b9113c3d93585eda893ed
On the Windows platform, the entire "global" address space is not
mapped in the inferior memory.  For such configuration, part of the
global address space lives in GPU memory, and can only be accessed via
rocm-dbgapi.

This patch updates amd_dbgapi_target::xfer_partial so it always calls
into amd-dbgapi to access the global address space.  GDB will still be
called to access host memory using xfer_global_memory callback.

To be sure that the callback request is not routed back to dbgapi, the
xfer_global_memory callback is modified to route the request to
whichever target sits below the amd-dbgapi target on the target stack.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I2d5ca46edf65e2dec3606d18f7ad1d22d0275a63
gdb.base/segv.c uses raise(SIGSEGV) to generate a SIGSEGV.  On native
Windows that does not generate an EXCEPTION_ACCESS_VIOLATION; raise is
a pure userspace construct: it dispatches to the registered SIGSEGV
handler if there is one, otherwise calls abort.  GDB therefore never
sees an exception to intercept.  E.g.:

 ...
 continue
 Continuing.
 [Thread 1908.0x3308 (id 2) exited with code 3]
 [Inferior 1 (process 1908) exited with code 03]
 (gdb) FAIL: gdb.base/exitsignal.exp: trigger SIGSEGV (the program exited)
 continue
 The program is not being run.
 ...

Replace the raise with a real null dereference so the kernel actually
raises an access violation.

Note: I confirmed no other tests use segv.c.  segv.c and normal.c are
both "owned" by gdb.base/exitsignal.exp.

Change-Id: Ib54d9e6998cf9bfc18dcb5e76d31a9deb0458da4
On native Windows a segmentation fault is delivered as a SEH
exception, so GDB stops twice: once for the first-chance exception,
and -- if no SEH handler in the inferior catches it -- again for the
second-chance exception, after which the process dies.  The testcase
currently continues only once, resulting in:

 ...
 continue
 Continuing.

 Thread 1 received signal SIGSEGV, Segmentation fault.
 0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
 24        *(volatile int *) 0;
 (gdb) PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
 continue
 Continuing.

 Thread 1 received signal SIGSEGV, Segmentation fault.
 0x00007ff765ac1469 in main (argc=1, argv=0x9f2640) at C:/rocgdb/src.cascais-rsync/gdb/testsuite/gdb.base/segv.c:24
 24        *(volatile int *) 0;
 (gdb) FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
 ...

Add a second continue on MinGW to step past the second-chance stop.

With this, gdb.base/exitsignal.exp passes cleanly on MinGW:

 -FAIL: gdb.base/exitsignal.exp: program terminated with SIGSEGV
 +PASS: gdb.base/exitsignal.exp: trigger SIGSEGV, second-chance
 +PASS: gdb.base/exitsignal.exp: program terminated with SIGSEGV

Change-Id: Ibda1540a602b62c26a5b218d930402eccc3ba98f
Currently, gdb.base/exitsignal.exp on MinGW skips half the tests, like
so:

 # of expected passes            13
 # of untested testcases         1

... because the testcase actually compiles two programs, but the
second program is compiled using the same executable name as the
first, at a time when gdb still has the first executable open,
resulting in:

 .../x86_64-w64-mingw32/bin/ld.exe: cannot open output file C:/.../gdb.base/exitsignal/exitsignal.exe: Permission denied

The use of standard_testfile in the middle of a testcase is a bit
surprising.  Fix this by moving the second compilation to the top, and
give each executable its own name.

Move the bulk of test code to two procedures, one for testing exiting
with signal, another for testing normal exit.

With this, gdb.base/exitsignal.exp passes cleanly on
x86_64-w64-mingw32.

Change-Id: I9a1af298b0e4f62f38b5c4b14787d7e40a2b5e2c
gdb.base/exitsignal.exp currently tests exiting with exit code 0.
But, testing for 0 is typically more "dangerous" in the sense that
it's easy for some bug in GDB or the target backend to fail to extract
the exit code and return 0.  Make it test exit code 1 instead.

gdb.base/coredump-filter-build-id.exp currently reuses normal.c.  It
could still use it with this patch, but it seems better to me to
remove the coupling.  Simply add a new .c file for that testcase,
which still returns 0.

Change-Id: I49ccfdbbe4be4445172476e7dd4e06142c8a672e
On some targets, like Cygwin (see the following commit), extracting
the exit code works differently depending on whether the inferior was
run by GDB, or GDB attached to an existing process.  Extend
gdb.base/exitsignal.exp to test both scenarios.

Note: We add a wait_for_gdb sleep loop to segv.c and normal.c so the
attach path can synchronize with GDB before the inferior runs.  For
simplicity, the run path pokes the same variable from setup, so
behavior there is unchanged.

The testcase passes cleanly on Linux, native and gdbserver, and on
MinGW too.  Cygwin still requires more fixes.

Change-Id: I9908aef0cea3eaec8134f05e347702baf753d10c
…gwin

This adds a new "win32" option to gdb_compile that lets us compile
native Windows programs when testing Cygwin.  Will be used in a
following patch.

The testsuite tries to find the compiler to use automatically.  You
can also explicitly set it with WIN32_CC_FOR_TARGET.

Change-Id: I86e954494cf7f88164cdf1c9127be46d5437986f
Move the exit status logic added by commit 559e7e5 ("Improve
process exit status macros on MinGW") from both GDB and GDBserver to a
shared routine used by both.

The next patch extends this routine with Cygwin-specific decoding.

Change-Id: I4bf08c6beff0d1688064a81d49bbdd615643735e
On native Cygwin, GDB misreports the inferior's exit reason in several
common cases, resulting in several gdb.base/exitsignal.exp failures:

 $ grep FAIL gdb.sum
 FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after SIGSEGV.
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after SIGSEGV
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitsignal is 11 (SIGSEGV) after restarting the inferior
 FAIL: gdb.base/exitsignal.exp: how=run: signal: $_exitcode is still void after restarting the inferior
 FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit
 FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitcode is one after normal inferior is executed
 FAIL: gdb.base/exitsignal.exp: how=run: normal: $_exitsignal is still void after normal inferior is executed
 FAIL: gdb.base/exitsignal.exp: how=attach: normal: continue to exit (the program exited)
 FAIL: gdb.base/exitsignal.exp: how=attach: normal: $_exitcode is one after normal inferior is executed

For example, from gdb.log, the normal exit case:

 ...
 [Thread 14300.0x4214 (id 1) exited with code 1]
 [Thread 14300.0x1b1c (id 4) exited with code 1]
 [Thread 14300.0x1e2c (id 2) exited with code 1]

 Program terminated with signal SIGHUP, Hangup.
 The program no longer exists.
 (gdb) FAIL: gdb.base/exitsignal.exp: how=run: normal: continue to exit

The program in fact exited normally with code 1.  SIGHUP happens to be
signal 1, and GDB picked the wrong interpretation.

Similarly, for the signal termination case:

 ...
 continue
 Continuing.
 [Thread 4600.0x3104 (id 4) exited with code 2816]
 [Thread 4600.0x2bcc (id 3) exited with code 2816]
 [Thread 4600.0x2f44 (id 1) exited with code 2816]
 [Inferior 1 (process 4600) exited with code 05400]
 (gdb) FAIL: gdb.base/exitsignal.exp: how=run: signal: program terminated with SIGSEGV (the program exited)

Here the inferior died with SIGSEGV, but GDB reported exit decimal
2816 / octal 05400 / hex 0x0B00, which is SIGSEGV swapped into the
high byte of a waitpid exit status.

The problem is that Cygwin waitpid exit status and Windows exit codes
do not have the same encoding, and GDB & GDBserver do not know about
this.

This commit fixes it.  It adds a Cygwin-specific branch to the code
that determines the terminating signal and status of a program.  The
branch for native Windows/MinGW GDB is left intact, no behavior change
there.

The way to decode the exit codes is a little bit tricky, see detailed
comments added by the patch.  To exercise the "raw NTSTATUS error
code" path in windows_process_info::exit_process_to_target_status,
gdb.base/exitsignal.exp is extended to debug a native Windows program
that crashes with a segfault (STATUS_ACCESS_VIOLATION).

With this, gdb.base/exitsignal.exp passes cleanly on Cygwin.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Icaebcc234b71927915c996fd120884604441415b
This commit fixes a couple issues in gdb.python/py-events.exp for
Cygwin and MinGW:

1) - GDB prints Windows thread IDs in hex:

 (gdb) thread
 [Current thread is 1 (Thread 9528.0xa9c)]

The current code assumes decimal, so we only (incorrectly) extract the
"0" after the dot.

2) - Thread and process ID number spaces are different.

The current code assumes that the extracted thread ID is the same
number as the extracted process ID, which is not true on Windows.

Also tested on x86_64-unknown-linux-gnu.

Change-Id: Iebcc07c3ad0845b548334c0d5177b3ab9e9350cf
The gdb.python/py-events.exp testcase currently uses fork, and relies
on "set detach-on-fork off".

Cygwin does support the fork syscall, but GDB can't follow forks
there, so "detach-on-fork off" has no effect.  And also, there is no
fork on native Windows, which makes the testcase unusable on MinGW
currently.

I don't see any reason the testcase needs to use fork or multiple
inferiors.  We can replace what those parts were testing by more
focused tests:

 - The clear_objfiles event was tested via following a fork.  Instead,
   test a more directed "file" command.

 - Two-inferior quit was being used to test that gdb.ExitedEvent has
   no "exit_code".  Quitting while an inferior is being debugged makes
   GDB kill the inferior.  What's really being tested is the kill
   path, so write an explicit (single-inferior) kill test.

Tested on x86_64-unknown-linux-gnu.

Change-Id: I21ee8af7b52653c6fdff9b4c1596cdde3cfe751a
…erior"

The testcase is using "info proc" to extract the inferior's process
ID.  But "info proc" does not exist on all targets, including Windows.
Switch to using the get_inferior_pid routine from lib/gdb.exp, which
uses "inferior" instead.

With this fixed, the testcase passes cleanly on Cygwin.  I haven't
tested on MinGW (I'm not set up for Python testing there currently),
but at least (since the previous patches) the test should be able to
compile & run there now.

Also tested on x86_64-unknown-linux-gnu.

Change-Id: If6ff482ceb011d9afe5ed40ef7e4e2f2cad8cae8
Coverage testing showed that there were no existing tests of the Ada
"in" operator.  This patch adds tests for this.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34041
Add checks in a couple of places for a non-NULL return.  While we're
at it, don't use sprintf to concatenate two strings.

	* elflink.c (bfd_elf_link_record_dynamic_symbol): Check than
	bfd_malloc returns non-NULL.
	(get_dynamic_reloc_section_name): Similarly check bfd_alloc.
	Replace sprintf with two memcpys.  Remove old_name NULL check.
Yet another case where a fuzzed object file triggers a crash in the
vms-alpha support.

	* vms-alpha.c (image_write_section): Don't segfault on NULL
	image_section.
Convert gdb.dwarf2/dw2-strp.exp to dwarf assembly using
gdb/contrib/dwarf-to-dwarf-assembler.py.

Tested on x86_64-linux.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
This fixes an issue that was reported here:

  https://inbox.sourceware.org/gdb-patches/v3x4md2dg6rflq35ymzwrmmqf5uaem5exrnlbsp5dmhph2vihy@lq22ncu774yu

After commit:

  commit 3780b99
  Date:   Fri Mar 27 11:29:07 2026 +0000

    gdb: refactor core_target ::close and ::detach functions

it was observed that the Python 'exited' event was no longer being
emitted when debugging a core file, and then exiting GDB.

The problem is that, when GDB is exiting we eventually end up in
quit_force (in top.c), which calls kill_or_detach for every inferior.

In kill_or_detach we call either target_detach or target_kill, but
only for non-core file targets.  For core file targets, neither of
these is called and kill_or_detach does nothing of interest.

After the call to kill_or_detach, we call inferior::pop_all_targets,
which calls inferior::pop_all_targets_above the dummy_stratum target,
which means popping all targets.

In inferior::pop_all_targets_above (in inferior.c), we call
switch_to_inferior_no_thread, which ensures the correct inferior is
selected, but makes it so that no thread is selected.  Switching to no
thread sets inferior_ptid to null_ptid.

Now popping the core_target calls core_target::close, and within
core_target::close we currently check inferior_ptid in order to
determine if exit_core_file_inferior has already been called or not.
We only call exit_core_file_inferior if inferior_ptid is not
null_ptid, so in this case we will not call exit_core_file_inferior.

The only other place that exit_core_file_inferior can be called from
is core_target::detach, but remember we specifically avoided calling
target_detach earlier in kill_or_detach.  This means that
exit_core_file_inferior ends up never being called.

It is exit_core_file_inferior that calls exit_inferior, and it is from
here that the Python 'exited' event is emitted.

I don't see any reason why kill_or_detach couldn't call target_detach
for a core file target, but I don't propose making that change in this
commit.

The check against inferior_ptid in core_target::close is clearly
incorrect, checking this requires that a suitable thread within the
inferior be selected, and that is not really a requirement for closing
a core_target.  Instead, we can just check the inferior::pid field.
When we open a core_target we always set inferior::pid, even if we
just assign a fake CORELOW_PID value, so checking inferior::pid
against zero will tell us if the inferior has already been exited.
Fixing this check is enough to resolve the reported bug and ensure
that the 'exited' event is always emitted, which is why I don't
propose changing kill_or_detach in this commit.

An assert in core_target::exit_core_file_inferior has to go too for
the same reason, the assert is checking that a thread is currently
selected, and as discussed above, this is not always the case.

There's a new test which checks that the 'exited' event is emitted for
a core file debug session, a native debug session where the inferior
is started by GDB, and a native debug session where GDB attaches to an
already running inferior.

Only the core file case was broken before this commit, but more
testing is always a good thing.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Approved-By: Pedro Alves <pedro@palves.net>
Claude Code mentioned in a review that a source file was marked executable.

I've submitted a patch to fix this [1].

Detect this problem using pre-commit to prevent it from re-occurring.

The state before commit 15363a3 ("[gdb] Drop executable mode in some
files") gives us (abbreviated output using "..."):
...
$ pre-commit run check-file-mode --all-files
check-file-mode.........................................................Failed
- hook id: check-file-mode
- exit code: 1

100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.h
100755 ... gdb/testsuite/gdb.fortran/nested-funcs.f90
100755 ... gdb/testsuite/gdb.fortran/oop_extend_type.f90
100755 ... gdb/amd64-tdep.c
100755 ... gdb/testsuite/lib/compiler.cc
100755 ... gdb/testsuite/gdb.fortran/nested-funcs.exp
100755 ... gdb/testsuite/gdb.fortran/vla-type.f90
100755 ... gdb/testsuite/gdb.arch/amd64-lam.c
100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.exp
100755 ... gdb/testsuite/gdb.testsuite/gdb_test_multiple-lbl.gdb
100755 ... gdb/testsuite/gdb.btrace/exception.exp
100755 ... gdb/testsuite/gdb.fortran/vla-type.exp
100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles.c
100755 ... gdb/testsuite/gdb.base/jump_multiple_objfiles-foo.c
100755 ... gdb/testsuite/gdb.fortran/oop_extend_type.exp
100755 ... gdb/testsuite/gdb.fortran/print_type.exp
...

Shell-checked new script gdb/contrib/check-file-mode.sh.

Changes in v2:
- make sure git failure makes the script fail
- make case statement more readable

Versions:
- v1 https://sourceware.org/pipermail/gdb-patches/2026-June/227791.html

[1] https://sourceware.org/pipermail/gdb-patches/2026-June/227780.html
With current trunk we have:
...
$ pre-commit run check-file-mode --all-files
check-file-mode.........................................................Failed
- hook id: check-file-mode
- exit code: 1

100755 ... gdb/microblaze-linux-nat.c
...

Fix this using chmod -x.
With current trunk we have:
...
$ pre-commit run flake8 --all-files
flake8..................................................................Failed
- hook id: flake8
- exit code: 1

gdb.python/py-inf-exited-at-exit.py:22:1: F821 undefined name 'gdb'
...

Fix this by adding the missing import.
For each word in codespell-ignore-words.txt, add a line briefly describing
its meaning.
Add more words to ignore in codespell-ignore-words.txt.
Fix typos in the gdb dir.
Fix codespell false positives in the gdb dir, by ignoring them.
Fix codespell false positive in gdb dir, by string splitting.
Fix codespell false positives in gdb dir, by renaming identifiers and
splitting words.
Include the files in the gdb dir in the codespell pre-commit check.
Simplify the codespell configuration in .pre-commit-config.yaml by moving the
file selection to gdb/pyproject.toml.
vries and others added 6 commits June 15, 2026 13:29
Result of:
...
$ codespell --toml gdb/pyproject.toml -w -i3 gdb/microblaze-linux-nat.c
/* Transfering floating-point registers between GDB, inferiors and cores.
	Transfering ==> Transferring (Y/n)
FIXED: gdb/microblaze-linux-nat.c
  gdb/microblaze-linux-nat.c:97: Transfering ==> Transferring
...
A recent codespell cleanup in gdb/testsuite made some files and a dir in the
codespell skip list codespell-clean.  Drop these from the skip list.
Replace all dirs in the codespell skip list with the actual files that are not
codespell-clean.  At this point, there's just ~60 of them.

This enables codespell checking for yet more files.
Add endianity to codespell-ignore-words.txt, as per this review comment [1].

[1] https://sourceware.org/pipermail/gdb-patches/2025-December/223137.html
Sync recent changes to libiberty.

include/ChangeLog:

	* libiberty.h (expandargstr): Declare.

libiberty/ChangeLog:

	* argv.c (expandargstr): New function.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
@lancesix lancesix requested a review from a team as a code owner June 16, 2026 10:15
@lancesix lancesix force-pushed the users/lancesix/merge-2026-06-16 branch 2 times, most recently from 2adde52 to f6d6ffe Compare June 16, 2026 10:25
@palves

palves commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

The set_unbuffered_mode_saved.o changes have a problem.

To see it easily, you can force that code path to run on linux too with this hack:

diff --git i/gdb/testsuite/lib/gdb.exp w/gdb/testsuite/lib/gdb.exp
index a38178a24ed..0b6405717bf 100644
--- i/gdb/testsuite/lib/gdb.exp
+++ w/gdb/testsuite/lib/gdb.exp
@@ -6923,9 +6923,9 @@ proc gdb_compile {source dest type options} {
   }
 
     if { $type == "executable" } {
-       if { ([istarget "*-*-mingw*"]
+       if {1 || ( ([istarget "*-*-mingw*"]
              || [istarget "*-*-*djgpp"]
-             || [istarget "*-*-cygwin*"])} {
+             || [istarget "*-*-cygwin*"]))} {
            # Force output to unbuffered mode, by linking in an object file
            # with a global constructor that calls setvbuf.
            #

and with that, we get:

Running /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp ...
ERROR: tcl error sourcing /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.rocm/simple.exp.
ERROR: tcl error code TCL LOOKUP SUBCOMMAND basename
ERROR: unknown or ambiguous subcommand "basename": must be atime, attributes, channels, copy, delete, dirname, executable, exists, extension, isdirectory, isfile, join, link, lstat, mkdir, mtime, nativename, normalize, owned, pathtype, readable, readlink, rename, rootname, separator, size, split, stat, system, tail, tempfile, type, volumes, or writable
    while executing
"file basename  [file rootname $::gdb_saved_set_unbuffered_mode_obj_name  ]  "
    (procedure "gdb_compile" line 514)
    invoked from within

"file basename" doesn't exist. It's spelled "file tail" instead.

$ rlwrap tclsh
file tail a/b/c.o
c.o

But then I don't understand why we'd need to extract the basename, since gdb_saved_set_unbuffered_mode_obj_name is always a basename, never a full path. So I think not calling "file tail" or anything at all would work. Like:

	set unbuf_obj_basename \
	    [file rootname $::gdb_saved_set_unbuffered_mode_obj_name]-$unbuf_obj_lang.o

That works for me on Linux with the hack above. Not sure if I missed something, though.

While at it, typo in commit log: becauso => because

@palves palves assigned lancesix and unassigned palves Jun 23, 2026
@lancesix lancesix force-pushed the users/lancesix/merge-2026-06-16 branch from f6d6ffe to 1fd21d1 Compare June 23, 2026 12:25
@lancesix

Copy link
Copy Markdown
Collaborator Author

Fixed, applied the change as suggested.

@lancesix lancesix force-pushed the users/lancesix/merge-2026-06-16 branch from 1fd21d1 to 5339de1 Compare June 23, 2026 12:29
@lancesix

Copy link
Copy Markdown
Collaborator Author

I had to rebase the merge as well, here is the delta between rebase and fixed patch:

diff --git a/gdb/amd-dbgapi-target.c b/gdb/amd-dbgapi-target.c
index 0d905e93eca..0e89953c283 100644
--- a/gdb/amd-dbgapi-target.c
+++ b/gdb/amd-dbgapi-target.c
@@ -992,7 +992,7 @@ amd_dbgapi_target::thread_name (thread_info *tp)
 
      Some kernel entry point functions have very long names, so we
      have a hardcoded length limit.  Very long names are not really
-     useful to users, and would make "info threads" output unuseable
+     useful to users, and would make "info threads" output unusable
      otherwise.  If the function name is longer than the limit, we
      trim it and append a 4-characters hash of the trimmed function
      name so that two trimmed function names with the same prefix
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index d1b6328cee8..ae009aeaf50 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -6972,9 +6972,7 @@ proc gdb_compile {source dest type options} {
                # which is important for GDB_PARALLEL.  See comments
                # above.
                set unbuf_obj_basename \
-                   [file basename \
-                     [file rootname $::gdb_saved_set_unbuffered_mode_obj_name \
-                     ] \
+                   [file rootname $::gdb_saved_set_unbuffered_mode_obj_name \
                    ]-$unbuf_obj_lang.o
                set unbuf_obj [standard_temp_file $unbuf_obj_basename]

@lancesix lancesix assigned palves and unassigned lancesix Jun 23, 2026
Handle conflicts introduced by recent upstream changes.  Conflicting
upstream changes are:
- c4aa08d gdb/amd-dbgapi-target: Move Linux code to amd-dbagapi-posix-hdep.c
- f67ddc1 gdb/amd-dbgapi-target: Update xfer_partial to always use dbgapi
- c04f1f5 gdb/testsuite: Add mechanism to compile Windows native programs on Cygwin
- 2b5689d [gdb/contrib] Describe words in codespell-ignore-words.txt

Most changes were trivial.  The main notable changes are in
gdb/testsuite/lib/gdb.exp, because of downstream change 27f8b77 "HIP
and set_unbuffered_mode_saved.o".

This merge commit also corrects one typo as codespell have been enabled
for the gdb directory by 664cc2d [pre-commit] "Include gdb in
codespell check".

Change-Id: If845e1d08c00f9e758f71d9b40e836a162c6c25a
@lancesix lancesix force-pushed the users/lancesix/merge-2026-06-16 branch from 5339de1 to 0e58174 Compare June 23, 2026 14:12
@lancesix lancesix merged commit 0e58174 into amd-staging Jun 23, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants