gas, bfd, gold: Rename Arm v8/v9 architecture tags

Rename the Arm AEABI CPU architecture tag constants and macro definitions to include the
profile suffix for A-profile architectures. This makes the naming
consistent with existing v8-R and v8-M tag names, while preserving the
existing numeric tag values.

Update BFD, GAS and Gold usage accordingly, including attribute combination
tables, architecture checks, and mach selection.

Automatic date update in version.in

x86: Check XMM destination when optimizing 128-bit VPBROADCASTQ

commit eb4031cb20aa710834be891f8638e04dbba81edc
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Jul 4 17:07:26 2023 +0200

    x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ

was supposed to optimize

vpbroadcastq %xmmN, %xmmM  -> vpunpcklqdq %xmmN, %xmmN, %xmmM (N < 8)

But it didn't check if the destination operand is XMM.  As the result, it
turned:

vpbroadcastq %xmmN, %ymmM

into

vpunpcklqdq %xmmN, %xmmN, %xmmM

Fixing it by checking XMM destination.

PR gas/34171
* config/tc-i386.c (optimize_encoding): Check XMM destination
when optimizing 128-bit VPBROADCASTQ.
* testsuite/gas/i386/optimize-2.d: Updated.
* testsuite/gas/i386/optimize-2.s: Add 256-bit vpbroadcastq.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

gdb/aarch64: record/replay support for LSE128

FEAT_LSE128 introduces support for 128-bit atomic instructions. This
patch teaches GDB to decode these instructions for recording and
reversing.

Regression tested on aarch64-none-linux-gnu on QEMU with LSE128 support.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

gdb/aarch64: Test record/replay support for CSSC

GDB can handle AArch64's CSSC instructions but there were no tests
ensuring that and ensuring no regressions would creep in. This commit
adds some tests for these instructions. This was tested on
aarch64-none-linux-gnu on QEMU with CSSC support.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

Re: alpha: Properly handle local weak undefined symbols

asan complains "runtime error: member access within null pointer"
for &h->root with NULL h, which is annoying since &h->root is the
same address as h, causing
alpha-linux-gnu  +FAIL: TLS -fpic -shared
alpha-linux-gnu  +FAIL: TLS -fpic and -fno-pic exec
alpha-linux-gnu  +FAIL: TLS -fpic and -fno-pic exec -relax

* elf64-alpha.c (elf64_alpha_relocate_section): Fix asan
complaint.

gdb/solib-rocm: add support for file URI on Windows

For processes using the ROCm runtime, GPU code objects are reported to
the debugger in the form of a URI (those are available to GDB using the
amd_dbgapi_process_code_object_list function and query the
AMD_DBGAPI_CODE_OBJECT_INFO_URI_NAME property).  Each URI can be of 2
forms:
  - "memory://$PID/mem#offset=$ADDR&size=$SIZE"
  - "file://$PATH#offset=$OFFSET&size=$SIZE"

On the Windows platform, only the "memory" URI form is used at the
moment, but future runtime changes might make it report code objects
using the "file" form.  When using the "file" form, when the runtime
reports an absolute path, the URI will look something like this:

    file:///C:/foo/bar/file.exe#offset=0x123&size=0x321

The decoding scheme currently implemented in
gdb/solib-rocm:rocm_bfd_iovec_open would extract the file path as
"/C:/foo/bar/file.exe", and will eventually hand this path to
solib_open.

Surprisingly enough, solib_open still manages to locate the file
properly.  This is due to the following of code which effectively drops
the leading "/" turning the path into a valid absolute path which can
eventually be opened.

    /* If the search in gdb_sysroot failed, and the path name is
       absolute at this point, make it relative.  (openp will try and open the
       file according to its absolute path otherwise, which is not what we want.)
       Affects subsequent searches for this solib.  */
    if (found_file < 0 && IS_TARGET_ABSOLUTE_PATH (fskind, in_pathname))
      {
        /* First, get rid of any drive letters etc.  */
        while (!IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
          in_pathname++;

        /* Next, get rid of all leading dir separators.  */
        while (IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
          in_pathname++;
      }

This patch proposes to fix rocm_solib so we properly decode the file
path and give a valid path to solib_open to properly support this
scheme.

Note that this patch only looks for forward slashes "/" in the pattern
matching and not the traditional backslashes (as IS_TARGET_DIR_SEPARATOR
would) as URIs use forward slashes, not backslashes.

Current GDB does not really AMDGPU debugging on Windows (there are still
a couple of missing necessary pieces), but this patch can still be
applied upstream and will eventually be needed.  I have tested this
patch on top of the downstream ROCgdb windows branch[1].  I have also
tested this patch on Linux + gfx1031 on top of master to ensure this
causes no regression.

[1] https://github.com/ROCm/ROCgdb/tree/amd-temp-windows

Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I10a1a32167007d5613e5a8696918bad5438285f3

Automatic date update in version.in

x86/disasm: do not use format string without format specifiers

Fixes PR binutils/34168: build failure with -Werror=format-security.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34168

Signed-off-by: Will Hawkins <hawkinsw@obs.cr>

Sync thread state after infcalls with "set unwind-on-* on" (PR gdb/34148)

Commit 519774805a1 ("Don't pretend infcalls don't set the inferior
running (PR gdb/34082)") removed the special case in proceed that
skipped set_state(THREAD_RUNNING) for infcalls.  That fixed
gdb.threads/hand-call-new-thread.exp, but introduced a regression in
gdb.compile/compile.exp:

 ...
 set unwind-on-signal on
 (gdb) PASS: gdb.compile/compile.exp: set unwind-on-signal on
 compile code *(volatile int *) 0 = 0;
 The program being debugged received signal SIGSEGV, Segmentation fault
 while in a function called from GDB.  GDB has restored the context
 to what it was before the call.  To change this behavior use
 "set unwind-on-signal off".  Evaluation of the expression containing
 the function (_gdb_expr) will be abandoned.
 (gdb) PASS: gdb.compile/compile.exp: compile code segfault second
 break 132
 Breakpoint 2 at 0x555555555262: file .../compile.c, line 132.
 (gdb) continue
 Cannot execute this command while the selected thread is running.
 (gdb) FAIL: gdb.compile/compile.exp: continue to breakpoint: break-here

The "compile code" command before the FAIL is an infcall under the
hood.  That hits SIGSEGV with "set unwind-on-signal on" in effect, so
GDB unwinds and abandons the call.  After that, "continue" is rejected
because the thread is still marked THREAD_RUNNING from the proceed
that started the infcall.

When an infcall is unwound due to a signal, timeout, or terminating
exception, call_thread_fsm::should_notify_stop returns false, and so
normal_stop is not called from fetch_inferior_event.  normal_stop is
what would normally call finish_thread_state to sync the public thread
state back to THREAD_STOPPED.  run_inferior_call has a fallback
finish_thread_state call for that purpose, but it is gated on
stop_stack_dummy == STOP_STACK_DUMMY, which is only true for
successful calls.

Before the commit mentioned above, proceed never marked an infcall's
thread as THREAD_RUNNING, so the missing RUNNING => STOPPED transition
was harmless.  The old comment in infcall.c about the
finish_thread_state call claimed "If the infcall does NOT succeed,
normal_stop will have already finished the thread states", but that
was already incorrect for the unwind paths.  It just happened to not
matter.

Fix this by dropping the STOP_STACK_DUMMY guard and updating the
comment to describe the actual rule: sync regardless of how the call
ended.  The !was_running check is kept since it is there to exclude
the in-cond-eval case, where the thread is meant to stay marked
running.  finish_thread_state is idempotent, so the call is harmless
on paths where normal_stop also ran.

Extend gdb.base/unwindonsignal.exp to exercise the "set
unwind-on-signal on" path without having to rely on the "compile code"
feature.  Without the fix, the test fails like so:

 info threads
   Id   Target Id                                           Frame
 * 1    Thread 0x7ffff7f8f740 (LWP 239019) "unwindonsignal" (running)
 (gdb) FAIL: gdb.base/unwindonsignal.exp: thread is stopped
 continue
 Cannot execute this command while the selected thread is running.
 (gdb) FAIL: gdb.base/unwindonsignal.exp: continue until exit at after unwound infcall

Similarly, extend gdb.cp/gdb2495.exp for "set
unwind-on-terminating-exception on", and gdb.base/infcall-timeout.exp
for "set unwind-on-timeout on".  Both would fail without the code fix,
too.

With the fix, gdb.compile/compile.exp now passes cleanly.

Tested on x86_64-unknown-linux-gnu.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34148
Change-Id: Idef0dcd4dd751b501869c58b752f77d4dadb6c72

buffer overflow in nds32_elf_lo12_reloc

nds32_elf_lo12_reloc reads the lo reloc word when processing stashed
hi relocs.

* elf32-nds32.c: Replace bfd_octets_per_byte with OCTETS_PER_BYTE
throughout file.
(nds32_elf_lo12_reloc): Sanity check reloc offset.

aarch64 core: use of uninitialised value

Commit d0ff5ca959df adding PT_AARCH64_MEMTAG_MTE support, creates
a section that stores "p_memsz" from the program header in "rawsize"
and "p_filesz" in "size".  p_memsz is the memory range, usually 32
times p_filesz.  This can be a problem when bfd reads the section, for
example to display it with objdump -s, as the usual (linker) meaning
for input section "rawsize" is the original size on disk.  Memory is
allocated to read the larger of "size" and "rawsize".  So 32 times the
memory is allocated than what is really needed.

With fuzzed input "rawsize" can be smaller than "size" since the
header values are not sanity checked.  This results in section
contents with only the first "rawsize" bytes read from disk, the rest
being uninitialised.  Of course fuzzed input can also have very large
"rawsize" which might result in OOM.

One way of fixing this is to move the p_memsz value somewhere else
(output_offset would work, I think).  Another might be to qualify use
of rawsize by is_linker_input, but I haven't checked over all the bfd
code using rawsize.  And then there is this approach:

* bfd.c (bfd_get_section_limit_octets),
(bfd_get_section_alloc_size): Ignore rawsize in bfd_core.
* bfd-in32.h: Regenerate.

Automatic date update in version.in

Adjust gdb.base/exitsignal.exp for Cygwin

Cygwin has this feature where if the program is about to die with a
signal, and there's a debugger attached, it raises a SIGTRAP via
DebugBreak.  So if you try to pass a terminating signal to the
inferior, you see that SIGTRAP first, before the process exits with
the signal.  E.g.:

 Thread 1 "segfault" received signal SIGSEGV, Segmentation fault.
 0x0000000100401092 in main () at segfault.cc:5
 5         *(volatile int *)0;
 (gdb) c
 Continuing.
 Thread 1 "segfault" received signal SIGTRAP, Trace/breakpoint trap.
 0x00007ffe99d35a13 in KERNELBASE!DebugBreak () from C:/WINDOWS/System32/KERNELBASE.dll
 (gdb) bt
 #0  0x00007ffe99d35a13 in KERNELBASE!DebugBreak () from C:/WINDOWS/System32/KERNELBASE.dll
 #1  0x00007ffe896163b7 in break_here () at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/dcrt0.cc:473
 #2  0x00007ffe8962fe13 in try_to_debug () at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/exceptions.cc:599
 #3  exception::handle (e=0x7ffffc9b0, frame=<optimized out>, in=0x7ffffc4c0, dispatch=<optimized out>) at /usr/src/debug/cygwin-3.6.9-1/winsup/cygwin/exceptions.cc:812
 #4  0x00007ffe9c5e63df in ntdll!.chkstk () from C:/WINDOWS/SYSTEM32/ntdll.dll
 #5  0x00007ffe9c499497 in ntdll!RtlLocateExtendedFeature () from C:/WINDOWS/SYSTEM32/ntdll.dll
 #6  0x00007ffe9c5e5d1e in ntdll!KiUserExceptionDispatcher () from C:/WINDOWS/SYSTEM32/ntdll.dll
 #7  0x0000000100401092 in main () at segfault.cc:5
 (gdb) c
 Continuing.
 ...
 [Inferior 1 (process 8032) exited with code 05400]
 (gdb)

gdb.base/exitsignal.exp fails on Cygwin partly because it doesn't take
that into account.  This commit fixes it.

In addition, the typical adjustement for the fact that all programs
are multi-threaded on Windows is also necessary.

gdb.base/exitsignal.exp still won't pass cleanly on Cygwin yet.
That'll be finally fixed in a following patch.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I2d18e2604afe3a4f80987848e2c1cd307ed43401
commit-id: 013964ce

Fix "set cwd ..." on Cygwin, part 2

Even after the previous patch, on both native and gdbserver Cygwin, we
get:

 (gdb) set cwd /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal
 (gdb) start
 Temporary breakpoint 3 at 0x100401094: file /home/alves/rocm/gdb/src/gdb/testsuite/gdb.base/segv.c, line 26.
 Starting program: /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal.exe
 ❌️ Error creating process /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal.exe (error 6): The handle is invalid.
 (gdb)

On the native side, this is because in
windows_nat_target::create_inferior, we unconditionally convert
forward slashes to backward slashes:

  /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal
  =>
  \cygdrive\d\cygwin-gdb\build-testsuite\outputs\gdb.base\exitsignal

and then cygwin_conv_path(CCP_POSIX_TO_WIN_W) does nothing on such
path, as the backward slashes make the path not look like a Unix-style
path.

CreateProcess then fails to CD into that directory, as that's not a
real Windows native path.

The fix is to not do the slashes replacement on Cygwin.

On the GDBserver side, we're just completely missing the
cygwin_conv_path logic.  This commit adds it.  The code isn't shared
with GDB because GDB uses wide chars, and GDBserver uses narrow char.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I004f2a562757a566423f6acb9aecfcc1a7f2f746
commit-id: 85aa8c22

Fix "set cwd ..." on Cygwin, part 1

When running gdb.base/exitsignal.exp on Cygwin, we see:

 (gdb) set cwd /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal
 (gdb) run
 Starting program: /cygdrive/d/cygwin-gdb/build-testsuite/outputs/gdb.base/exitsignal/exitsignal
 Error converting inferior cwd: 28
 (gdb) FAIL: gdb.base/exitsignal.exp: runto: run to main

28 is ENOSPC.  But this isn't really literally no space left, though.
cygwin_conv_path documentation mentions that error code.

According to the Cygwin API documentation for cygwin_conv_path, the
function fails with ENOSPC ("No space left on device") when the size
of the destination buffer is smaller than what is required for the
conversion.  See:

 https://cygwin.com/cygwin-api/func-cygwin-conv-path.html

If we look closely at how the buffer size argument is being passed, we
see we have two problems here:

1) Incorrectly passing down the input buffer size instead of the
output size.

The code passes strlen(inferior_cwd) as the size of the destination
buffer (infcwd). However, the target Windows path format
(e.g. "D:\cygwin-gdb\..." in my case) could be longer or shorter than
the POSIX source path ("/cygdrive/d/...").  In my specific case, the
source string is 64 characters, while the target Windows string is 61
(wide) characters (and twice as many bytes).

2) Incorrectly passing character count instead of byte count

The conversion target token is CCP_POSIX_TO_WIN_W.  The _W means that
the destination buffer infcwd takes wide characters (wchar_t).  The
documentation states that the size argument is in bytes, not
characters.

This commit fixes it, by passing the byte size of the destination
buffer.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I70af6ef394f48da35ccc2e04ef764915e09e59de
commit-id: 66c930c2

[gdb/python] Boolify gdb_python_initialized

I noticed that while gdb_python_initialized is an int, there's also an
assignment using false:
...
  gdb_python_initialized = false;
...

Fix this by converting gdb_python_initialized to bool type.

Approved-by: Kevin Buettner <kevinb@redhat.com>

Automatic date update in version.in

alpha: Properly handle local weak undefined symbols

Since the local undefined TLS symbol address isn't mapped to any TLS
storage, it isn't usable.  Set its value to 0 to avoid relocation overflow.
When processing TLS relocations, elf_hash_table (info)->tls_sec can be
NULL if all TLS symbols are weak, hidden and undefined.  Don't assert
elf_hash_table (info)->tls_sec != NULL.  Always set dtp_base and tp_base
to 0 if elf_hash_table (info)->tls_sec == NULL.

bfd/

PR ld/34165
* * elf-bfd.h (elf_link_local_undefweak_p): New function.
* elf64-alpha.c (elf64_alpha_relax_got_load): Set dtp_base and
tp_base to 0 if elf_hash_table (info)->tls_sec == NULL.
(elf64_alpha_relocate_section):  Set the local undefined TLS
symbol value to 0.  Don't assert elf_hash_table (info)->tls_sec
!= NULL.

ld/

PR ld/34165
* testsuite/ld-alpha/alpha.exp: Run $srcdir/$subdir/*.d.
* testsuite/ld-alpha/tlsbin-undef.d: New file.
* testsuite/ld-alpha/tlsbin-undef.s: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef1.d: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef1.s: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef2.d: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef2.s: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef3.d: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef3.s: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef4.d: Likewise.
* testsuite/ld-alpha/tlsbin-weak-undef4.s: Likewise.
* testsuite/ld-alpha/tlspic-undef.d: Likewise.
* testsuite/ld-alpha/tlspic-undef.s: Likewise.
* testsuite/ld-alpha/tlspic-weak-undef1.d: Likewise.
* testsuite/ld-alpha/tlspic-weak-undef1.s: Likewise.
* testsuite/ld-elf/pr34165.c: Likewise.
* testsuite/ld-elf/tls.exp: Run PR ld/34165 test.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

hppa*64*-*-hpux*: Create dummy milli.a archive for binutils and ld tests

On cross builds, this fixes numerous test fails due to the milli.a
archive not being found.  On hppa*64*-*-hpux*, this fixes four fails
due to undefined symbols in the HP milli.a archive.

The change to objcopy.exp causes the "objcopy executable (pr25662)"
test to fail.  Previously, it didn't run because milli.a wasn't
found.

2026-05-24  John David Anglin  <danglin@gcc.gnu.org>

binutils/ChangeLog:

* testsuite/binutils-all/objcopy.exp: Append LDFLAGS to
ldflags for milli.a archive.
* testsuite/config/default.exp: Create dummy milli.a archive
in tmpdir/hppa.  Append " -Ltmpdir/hppa" to LDFLAGS.

ld/ChangeLog:

* testsuite/config/default.exp: Likewise.

"eqv involving dot" gas test and pdp11

This changes the eqv-dot test to make 'x' non-zero, so targets
(eg. i386-darwin) that silently ignore the value of fx_subsy in fixups
will fail the test.

When updating the test I noticed seriously odd expected output for
pdp11.  Why should .long write in different byte order when needing
fixups (".long z")?  That appears to be a bug in the pdp11
md_apply_fix, which reads section contents using pdp-endian but writes
them little-endian.  Fix that too.

gas/
* config/tc-pdp11.c (md_apply_fix): Use md_mumber_to_chars.
* testsuite/gas/all/eqv-dot.s: Move x to second .long.
* testsuite/gas/all/eqv-dot.d: Update expected result.
* testsuite/gas/all/eqv-dot-pdp11.d: Likewise, and use
source directive.
* testsuite/gas/all/eqv-dot-pdp11.s: Delete.
* testsuite/gas/all/gas.exp (do_930509a): Support pdp11.
* testsuite/gas/all/simple-forward.d: Likewise.

pr 34159, buffer overflow in fr30_elf_i32_reloc

Stop the fuzzed object file buffer overflow, and remove a FIXME.

* elf32-fr30.c (fr30_elf_i20_reloc, fr30_elf_i32_reloc): Handle
ld -r using bfd_elf_generic_reloc.  Sanity check reloc offset.

mips: section .note.gnu.build-id can't be allocated in segment

After modifying test_build_id_debuglink, mips-linux fails
objcopy --only-keep-debug tmpdir/testprog tmpdir/testprog.debug
with the above error.  This is due to .MIPS.abiflags and .reginfo
being made SHT_NOBITS but the .note.gnu.build-id which follows is
SHT_PROGBITS.  That tickles a bug in file offset tracking.

* elf.c (assign_file_positions_for_load_sections): When
resetting "off_adjust" for sections with contents following
sections without contents, put back "off" too.

binutils test_build_id_debuglink

I saw build-id-debuglink test failures on a number of targets due to
deleting the glibc source I'd used when building the cross toolchains.
The tests failed with timeouts.

$ objdump -Sl tmpdir/testprog.strip

tmpdir/testprog.strip:     file format elf64-ia64-little

Disassembly of section .init:

40000000000003b0 <_init>:
_init():
/home/alan/src/glibc-2.38/csu/../sysdeps/ia64/crti.S:137
^C

I don't know where debuginfod was looking to try to find that crti.S
source, but wherever it was took too long, and we aren't trying to
test debuginfod here.  So remove the extraneous source dependencies
by building with -shared -nostdlib.  When making this change I also
removed the code passing extra options to target_compile via
CFLAGS_FOR_TARGET.  Instead, pass extra options with additional_flags.

* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
Don't use CFLAGS_FOR_TARGET to pass extra options to
target_compile.  Instead use additional_flags.  Build test
with -fPIC -shared -nostdlib.

i386-dis.c: Remove trailing spaces

* i386-dis.c (print_insn): Remove trailing spaces.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Automatic date update in version.in

Implement native TLS support on Windows

GCC 16 introduced native TLS variables on Windows, so this adds
debugger support for them.

The fetch_tls_load_module_address gdbarch method is used to get the
address of _tls_index of the OBJFILE, which is then forwarded as LM_ADDR
to windows_get_thread_local_address.

The TLS slot for a module can be found in
TIB->thread_local_storage[_tls_index].

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Improve dwarf assembly for implicit const in .debug_names

In the assembly generated for the dwarf assembly for test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, there's this bit:
...
.uleb128        0x2003          /* DW_IDX_GNU_language */
.uleb128        0x21            /* DW_FORM_flag_present */
.sleb128        0x0002          /* DW_LANG_C */
...

As it happens, 0x21 is not DW_FORM_flag_present, but DW_FORM_implicit_const,
and the following entry is the value of the attribute.

Fix the comment, and make the relation between the two entries more clear by
printing:
...
.uleb128        0x2003          /* DW_IDX_GNU_language */
.uleb128        0x21            /* DW_FORM_implicit_const */
.sleb128        0x0002          /* DW_FORM_implicit_const value: DW_LANG_C */
...

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Add missing type_offset in gdb.dwarf/debug-names-tu.exp

With llvm-dwarfdump we run into this warning:
...
$ llvm-dwarfdump -a -v debug-names-tu > /dev/null
warning: DWARF type unit at offset 0x00000028 has its relocated type_offset \
  0x00000028 pointing inside the header
...

Fix this by adding the missing type_offset.

Likewise in gdb.dwarf2/debug-names-bad-cu-index.exp.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

[gdb/testsuite] Complete 64-bit port of gdb.dwarf2/dw2-skip-prologue.exp

Test-source gdb.dwarf2/dw2-skip-prologue.S was generated using 32-bit, and
subsequently ported to 64-bit using macro PTRBYTE.

When using 64-bit, there are some readelf -w warnings because the port to
64-bit is not complete.  Fix these warnings.

Likewise in gdb.dwarf/dw2-const.exp.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

[gdb/testsuite] Remove invalid .debug_line section in gdb.dwarf2/dw2-icycle.exp

Test-case source gdb.dwarf2/dw2-icycle.S contains an invalid .debug_line
section contribution, causing a readelf -w warning.

It's also unused, so fix the warning by removing it.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

Automatic date update in version.in

[binutils] Handle implicit const in .debug_names

I tried to use readelf to read the debug info for gdb test-case
gdb.dwarf2/debug-names-tu-dwarf5.exp, and ran into some trouble reading the
.debug_names section:
...
$ readelf -w debug-names-tu-dwarf5
  ...
Symbol table:
[  1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[  2] #53a2ae86 struct_with_int_member:readelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
 <0x3><2> DW_TAG_structure_type DW_IDX_type_unit=0 DW_IDX_GNU_language=0 DW_IDX_type_unitreadelf: Warning: Unrecognized form: 0
readelf: Error: end of data encountered whilst reading LEB
...

The .debug_names abbreviation table contains a DW_FORM_implicit_const entry:
...
.uleb128        0x2003          /* DW_IDX_GNU_language */
.uleb128        0x21            /* DW_FORM_implicit_const */
.sleb128        0x0002          /* DW_FORM_implicit_const value: DW_LANG_C */
...
and readelf doesn't support this.

Add support for DW_FORM_implicit_const in display_debug_names, such that we
get the expected:
...
Symbol table:
[  1] #eddb6232 _start: <0><1> DW_TAG_subprogram DW_IDX_compile_unit=0
[  2] #53a2ae86 struct_with_int_member: <0x3><2> DW_TAG_structure_type \
      DW_IDX_type_unit=0 DW_IDX_GNU_language=2
...

gas: Clarify documentation about @ and % usage in .section

In the documentation for the .section Assembler Directive for the ELF
format, clarify the instances where @ and % can be used.

Signed-off-by: Will Hawkins <hawkinsw@obs.cr>

x86/disasm: rework comment handling

Model this after operand handling, such that comments can be emitted in
the same order as operands. %rip-relative address comments remain
separate for now. While there correct style for the symbols associated
with immediates: These aren't "comment starts", but symbol names.

x86/disasm: avoid potentially leaking annotation buffers

Address the FIXME there by moving the free() invocation out of the if().

x86/disasm: "annotate immediates" flag should not be global

With disassembly functions having been made thread-safe, no new global
state variables should be introduced.

Extract SEH shared helpers into separate file

The patch moves SEH helpers to a separate shared file,
which will be reused by the SEH implementation on AArch64.

Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
gas/ChangeLog:

* config/obj-coff-seh.c (struct seh_seg_list): Move into
  obj-coff-seh-shared.c.
(get_pxdata_name): Likewise.
(alloc_pxdata_item): Likewise.
(make_pxdata_seg): Likewise.
(seh_hash_insert): Likewise.
(seh_hash_find): Likewise.
(seh_hash_find_or_make): Likewise.
(seh_validate_seg): Likewise.
(switch_xdata): Likewise.
(switch_pdata): Likewise.
(verify_context): Likewise.
(skip_whitespace_and_comma): Likewise.
* config/obj-coff-seh.h (OBJ_COFF_SEH_H): Add guard.
(obj_coff_seh_code): Likewise.
* config/obj-coff.c: Update.
* config/obj-coff-seh-shared.c: New file.

binutils: make x86-64/x86-64.exp work again by itself

The "exe" global is introduced only by some *.exp in the parent dir, which
may not be run.

Automatic date update in version.in

gdb: remove complaint_interceptor::g_complaint_interceptor

The thread_local g_complaint_interceptor pointer is unnecessary.  The
complaint_interceptor constructor registers itself as the warning hook
via m_saved_warning_hook (this), so when complaint_internal dispatches
through the warning hook, it lands in complaint_interceptor::warn with
'this' already pointing at the registered interceptor.  Inside warn,
g_complaint_interceptor and 'this' always refer to the same object.

Replace g_complaint_interceptor->m_complaints with m_complaints in
complaint_interceptor::warn and remove g_complaint_interceptor.

Change-Id: I75565a5f2c0e51363f36be0e3544210c10bb5491
Approved-By: Tom Tromey <tom@tromey.com>

gdb: lock complaint_mutex in clear_complaints

If I add a dummy complaint like

    complaint (_("I am a complaint"));

in cooked_index_worker_debug_info::process_unit, and then load a file
under a GDB built with ThreadSanitizer, I get this (trimmed for
readability):

    WARNING: ThreadSanitizer: data race (pid=497507)
      Read of size 4 at 0x7208000004c8 by thread T4 (mutexes: write M0):
        #0 std::pair<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::pair<char const*, int>*, std::__cxx1998::vector<std::pair<char const*, int>, std::allocator<std::pair<char const*, int> > > >, std::__debug::vector<std::pair<char const*, int>, std::allocator<std::pair<char const*, int> > >, std::random_access_iterator_tag>, bool> ankerl::unordered_dense::v4_8_0::detail::table<char const*, int, ankerl::unordered_dense::v4_8_0::hash<char const*, void>, std::equal_to<char const*>, std::allocator<std::pair<char const*, int> >, ankerl::unordered_dense::v4_8_0::bucket_type::standard, ankerl::unordered_dense::v4_8_0::detail::default_container_t, false>::do_try_emplace<char const* const&>(char const* const&) /home/simark/src/binutils-gdb/gdb/../gdbsupport/unordered_dense/unordered_dense.h:1227 (gdb+0xf0fd75) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #1 std::pair<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::pair<char const*, int>*, std::__cxx1998::vector<std::pair<char const*, int>, std::allocator<std::pair<char const*, int> > > >, std::__debug::vector<std::pair<char const*, int>, std::allocator<std::pair<char const*, int> > >, std::random_access_iterator_tag>, bool> ankerl::unordered_dense::v4_8_0::detail::table<char const*, int, ankerl::unordered_dense::v4_8_0::hash<char const*, void>, std::equal_to<char const*>, std::allocator<std::pair<char const*, int> >, ankerl::unordered_dense::v4_8_0::bucket_type::standard, ankerl::unordered_dense::v4_8_0::detail::default_container_t, false>::try_emplace<, int, true>(char const* const&) /home/simark/src/binutils-gdb/gdb/../gdbsupport/unordered_dense/unordered_dense.h:1701 (gdb+0xf0ec50) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #2 int& ankerl::unordered_dense::v4_8_0::detail::table<char const*, int, ankerl::unordered_dense::v4_8_0::hash<char const*, void>, std::equal_to<char const*>, std::allocator<std::pair<char const*, int> >, ankerl::unordered_dense::v4_8_0::bucket_type::standard, ankerl::unordered_dense::v4_8_0::detail::default_container_t, false>::operator[]<int, true>(char const* const&) /home/simark/src/binutils-gdb/gdb/../gdbsupport/unordered_dense/unordered_dense.h:1926 (gdb+0xf0e3e2) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #3 complaint_internal(char const*, ...) /home/simark/src/binutils-gdb/gdb/complaints.c:50 (gdb+0xf0abc6) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #4 cooked_index_worker_debug_info::process_unit(dwarf2_per_cu*, dwarf2_per_objfile*, cooked_index_worker_result*) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3162 (gdb+0x11d741c) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #5 cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}::operator()() const /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3068 (gdb+0x122b195) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #6 void cooked_index_worker_result::catch_error<cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}>(cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}&&) /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index-worker.h:122 (gdb+0x1236454) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #7 cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3066 (gdb+0x122b22d) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #8 cooked_index_worker_debug_info::parallel_indexing_worker::operator()(iterator_range<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*>) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3060 (gdb+0x122b0a3) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        ...

      Previous write of size 8 at 0x7208000004c8 by main thread:
        #0 __tsan_memset <null> (libtsan.so.2+0x95e66) (BuildId: b5c99e8ceaf9098eb9a01fcfcc35ece8603116df)
        #1 ankerl::unordered_dense::v4_8_0::detail::table<char const*, int, ankerl::unordered_dense::v4_8_0::hash<char const*, void>, std::equal_to<char const*>, std::allocator<std::pair<char const*, int> >, ankerl::unordered_dense::v4_8_0::bucket_type::standard, ankerl::unordered_dense::v4_8_0::detail::default_container_t, false>::clear_buckets() /home/simark/src/binutils-gdb/gdb/../gdbsupport/unordered_dense/unordered_dense.h:1116 (gdb+0xf0edd6) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #2 ankerl::unordered_dense::v4_8_0::detail::table<char const*, int, ankerl::unordered_dense::v4_8_0::hash<char const*, void>, std::equal_to<char const*>, std::allocator<std::pair<char const*, int> >, ankerl::unordered_dense::v4_8_0::bucket_type::standard, ankerl::unordered_dense::v4_8_0::detail::default_container_t, false>::clear() /home/simark/src/binutils-gdb/gdb/../gdbsupport/unordered_dense/unordered_dense.h:1494 (gdb+0xf0e479) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #3 clear_complaints() /home/simark/src/binutils-gdb/gdb/complaints.c:74 (gdb+0xf0adbf) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #4 finish_new_objfile /home/simark/src/binutils-gdb/gdb/symfile.c:986 (gdb+0x1a2c65d) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #5 symbol_file_add_with_addrs /home/simark/src/binutils-gdb/gdb/symfile.c:1111 (gdb+0x1a2cdde) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #6 symbol_file_add_from_bfd(gdb::ref_ptr<bfd, gdb_bfd_ref_policy> const&, char const*, enum_flags<symfile_add_flag>, std::__debug::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) /home/simark/src/binutils-gdb/gdb/symfile.c:1148 (gdb+0x1a2cfab) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #7 symbol_file_add(char const*, enum_flags<symfile_add_flag>, std::__debug::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>) /home/simark/src/binutils-gdb/gdb/symfile.c:1161 (gdb+0x1a2d03a) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #8 symbol_file_add_main_1 /home/simark/src/binutils-gdb/gdb/symfile.c:1185 (gdb+0x1a2d1a5) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #9 symbol_file_command(char const*, int) /home/simark/src/binutils-gdb/gdb/symfile.c:1615 (gdb+0x1a2ed10) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #10 file_command /home/simark/src/binutils-gdb/gdb/exec.c:580 (gdb+0x1305356) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        ...

      Location is heap block of size 32 at 0x7208000004c0 allocated by main thread:
        ...
        #11 __static_initialization_and_destruction_0 /home/simark/src/binutils-gdb/gdb/complaints.c:31 (gdb+0xf0df04) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        ...

      Mutex M0 (0x558908cdbc20) created at:
        #0 pthread_mutex_lock <null> (libtsan.so.2+0x60b5a) (BuildId: b5c99e8ceaf9098eb9a01fcfcc35ece8603116df)
        #1 __gthread_mutex_lock(pthread_mutex_t*) /usr/include/c++/16.1.1/x86_64-pc-linux-gnu/bits/gthr-default.h:795 (gdb+0xf0dfa6) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #2 std::mutex::lock() /usr/include/c++/16.1.1/bits/std_mutex.h:116 (gdb+0xf0dfa6)
        #3 std::lock_guard<std::mutex>::lock_guard(std::mutex&) /usr/include/c++/16.1.1/bits/std_mutex.h:276 (gdb+0xf0e1f0) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #4 complaint_internal(char const*, ...) /home/simark/src/binutils-gdb/gdb/complaints.c:49 (gdb+0xf0abad) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #5 cooked_index_worker_debug_info::process_unit(dwarf2_per_cu*, dwarf2_per_objfile*, cooked_index_worker_result*) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3162 (gdb+0x11d741c) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #6 cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}::operator()() const /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3068 (gdb+0x122b195) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #7 void cooked_index_worker_result::catch_error<cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}>(cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&)::{lambda()#1}&&) /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index-worker.h:122 (gdb+0x1236454) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #8 cooked_index_worker_debug_info::parallel_indexing_worker::process_one(dwarf2_per_cu&) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3066 (gdb+0x122b22d) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        #9 cooked_index_worker_debug_info::parallel_indexing_worker::operator()(iterator_range<std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*>) /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3060 (gdb+0x122b0a3) (BuildId: 5d682ab96882c738940aae3c2c67270d969f113f)
        ...

This points to clear_complaints touching the global counters map in the
main thread without holding a lock, while a background thread touched
the map in a worker thread while holding the lock complaint_mutex.

Fix this by holding the complaint_mutex lock in clear_complaints.

Change-Id: Id2fe442486bcdf57156aacdc9253055702c07600
Approved-By: Tom Tromey <tom@tromey.com>

gdb/dwarf: make dwarf2_per_bfd::get_unit return a reference

This method can't return nullptr, switch it to return a reference.
Change all_units_iterator::operator* too.

Change-Id: I15c945553abfebdcc8834438a3b45d9895d628f0
Approved-By: Tom Tromey <tom@tromey.com>

gdb/dwarf: track whether the all_units vector is sorted

dwarf2_find_unit performs a binary search over dwarf2_per_bfd::all_units
using std::lower_bound.  Before calling std::lower_bound, we want to
make sure that all_units is properly sorted.

Track the state of whether all_units is considered sorted with a new
dwarf2_per_bfd::all_units_sorted flag, and assert it in
dwarf2_find_unit.  This will help catch bugs where we call
dwarf2_find_unit on a non sorted vector, for instance what was fixed by
commit fbaef7de7701 ("gdb/dwarf: fix order of operations when reading
.debug_names").

The flag is set:

 - At initialization time, because an empty vector is sorted.

 - Whenever the vector is cleared, for the same reason (added a helper
   method for that).

 - After sorting in dwarf2_per_bfd::sort_all_unit.

It is cleared:

 - Whenever a unit is appended to all_units.  To keep this centralized,
   add a new dwarf2_per_bfd::add_unit helper that appends the unit and
   clears the flag.

 - Whenever a unit's sort key (section / sect_off) is modified.  That is
   done in dwarf2_per_cu::set_section and dwarf2_per_cu::set_sect_off.

Note that the flag is cleared when appending a unit even if the vector
would by chance already be sorted.  This is good, because it will catch
mistakes even on machines where a problem with std::lower_bound would
not manifest.

I checked that this patch would have caught the problem before commit
fbaef7de7701:

    (gdb) file /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index
    Reading symbols from /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index...
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18092: internal-error: dwarf2_find_unit: Assertion `per_bfd->all_units_sorted' failed.

Change-Id: I9b3e52bb33b02763594efa381761f383ee344317
Approved-By: Tom Tromey <tom@tromey.com>

gdb/dwarf: change signatured_type_up to include deleter type

We currently have:

  using dwarf2_per_cu_up = std::unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>;
  using signatured_type_up = std::unique_ptr<signatured_type>;

Meaning that it's not possible to pass a signatured_type_up as a
dwarf2_per_cu_up, even though the target types are related (it is
possible to pass a `signatured_type *` as a `dwarf2_per_cu *`).

If we give signatured_type_up the same deleter as dwarf2_per_cu_up, then
it becomes possible to pass a signatured_type_up as a dwarf2_per_cu_up.
This lets us avoid releasing a signatured_type_up only to create a
dwarf2dwarf2_per_cu_up immediately after in some spots.  The only
downside is that we can't use make_unique anymore, but it's already the
case for dwarf2_per_cu_up.

Swap the order of things in add_type_unit so that we don't need a
special holder variable.

Change-Id: Iee34e5d1711d601297f109e58cbaeccb5a0c6cde
Approved-By: Tom Tromey <tom@tromey.com>

Add test for Ada abs operator

There were no tests in the tree for the Ada abs operator, meaning that
ada_abs was never invoked during a test.  This patch adds a new basic
test for this.

Note that operator overloading of 'abs' does seem to be tested.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34042

Test attributes with array types

While looking at code coverage, I noticed that gdb was not testing the
case where certain attributes were applied to an Ada array type.  This
patch adds some new tests, improving the coverage.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34043

Combine ada_unop_atr and ada_unop_atr_operation::evaluate

This inlines ada_unop_atr into its sole caller.  This split was an
artifact of the expression type conversion.

[gdb/testsuite] Don't generate dummy CUs in dwz files

I came across .debug_aranges sections in .dwz files.  Fix this by skipping
dummy CU generation in .dwz files.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

[gdb/testsuite] Clean up duplicate .debug_aranges terminators

I came across duplicate .debug_aranges terminators:
...
aranges {} cu_start {
    arange {} 0 0
}
...

The dwarf assembler already generates a terminator, so there's no need to
generate another one.

Remove these.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

[gdb/testsuite] Clean up gdb.dwarf2/imported-unit-c.exp

In test-case gdb.dwarf2/imported-unit-c.exp there's some dwarf assembly that's
unused, and is causing readelf -w warnings.  Remove it.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34157

gdb/amd-dbgapi-target: suppress a repeated stop request

Sending a second stop request to an AMD GPU thread before fetching the
event caused by the first request leads to an error:

  wave_stop for wave_1 failed (The wave has an outstanding stop request)

Prevent sending a new stop request if there already is an outstanding
one.  The fix is in amd_dbgapi_target::stop.

A regression test is included.  The test uses non-stop mode and
executes the "interrupt" command twice, because in non-stop mode this
command uses the 'stop' target op, where the fix is applied.

To be able to execute two interrupt commands repeatedly, we define a
user command.

Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)

Automatic date update in version.in

gdb: Handle TYPE_CODE_COMPLEX in valprint_check_validity.

When printing complex variables with partial optimization (e.g., real
part available but imaginary part optimized out), GDB incorrectly
reported the entire variable as <optimized out> instead of showing
available components.

The issue occurred because valprint_check_validity () only exempted
TYPE_CODE_UNION, TYPE_CODE_STRUCT, and TYPE_CODE_ARRAY from the
optimized-out check, but not TYPE_CODE_COMPLEX.  Complex types, like
structures, can have components with different availability.

A new test gdb.dwarf2/complex-partial-optimized.exp is added to verify
that available components are printed.

(gdb) print z1
$1 = <optimized out>

Now after this change:

(gdb) print z1
$1 = 3 + <optimized out>i

Approved-By: Tom Tromey <tom@tromey.com>

gdb/dwarf: fix order of operations when reading .debug_names

PR 34149 shows a hard to reproduce bug.  The problem sometimes shows up
when reading in `.debug_names` indexes, manifesting like this:

    warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.

This is shown even if the CU table in the `.debug_names` index
accurately describes the CUs in `.debug_info`.

The bug was introduced by commit b301725d35c1 ("gdb/dwarf: read foreign
type units").

Before b301725d35c1, the steps when reading a `.debug_names` index were:

 - call to create_all_units(), which filled the all_units vector by
   walking `.debug_info` and `.debug_types` and then sorted it.
 - calls to the build_and_check_* functions, which do some lookups in
   the all_units vector, requiring it to be sorted.

All good.  Post-b301725d35c1, we have:

 - call to create_all_units(), which still fills the all_units vector by
   walking `.debug_info` and `.debug_types`, but does not sort it
   anymore.
 - calls to the build_and_check_* functions, which do some lookups in
   the all_units vector, requiring it to be sorted (oops)
 - call to create_foreign_type_units_from_debug_names(), which may add
   more items to the all_units vector.
 - call to finalize_all_units(), to sort the all_units vector.

The sorting of all_units was taken out of create_all_units() on purpose.
Because create_foreign_type_units_from_debug_names() may add more units,
we don't want to sort the vector in create_all_units() and then sort it
again after create_foreign_type_units_from_debug_names().

The build_and_check_* functions do some lookups in the all_units vector
with dwarf2_find_unit(), which uses std::lower_bound() internally.  This
happens while the all_units vector is not sorted according to the
sorting key, all_units_less_than(), which makes the search is bogus.
dwarf2_find_unit() might return "no such unit", when in fact, the given
unit exists.  This leads build_and_check_cu_list_from_debug_names() to
believe that the list of CUs in the `.debug_names` index does not match
what was built from reading `.debug_info`, we get the warning shown
above, and the index gets wrongfully rejected.

For this bug to show up, it is necessary to have type units in a
`.debug_types`.  The sorting key for units in the all_units vector is:
section pointer (`dwarf2_section_info *`), then the unit offset into the
section.  If all units come from the same section (`.debug_info`), then
this bug does not show up because the all_units vector happens to be
sorted after create_all_units() runs.  This happens for example in test
gdb.dwarf2/debug-names-bad-cu-index.exp, where we create some DWARF 4
units and then a `.debug_names` index out of them.

It must also happen for the `dwarf2_section_info *` for `.debug_types`
to be "less than" the `dwarf2_section_info *` for `.debug_info`,
otherwise the all_units also happens to be sorted after
create_all_units() runs.  This entirely depends on the whims of the
memory allocator.

I was not able to reproduce it in my normal GDB dev build, but I was
able in a "thread sanitizer" build, for some reason.  Not because there
is an actual threading issue, but I think because it shuffled the memory
allocations in just the right way to make the bug happen.  And then, it
only happened when doing "make check", I could not get it to reproduce
when running interactively.  Using -D_GLIBCXX_DEBUG was immensely
useful, because it pointed out that the "range must be sorted"
precondition for std::lower_bound() was not met, which made the problem
immediately obvious:

    (gdb) file /home/simark/build/binutils-gdb-tsan/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index
    Reading symbols from /home/simark/build/binutils-gdb-tsan/gdb/testsuite/outputs/gdb.dwarf2/debug-names-bad-cu-index/debug-names-bad-cu-index...
    /usr/include/c++/16.1.1/bits/stl_algo.h:1981:
    In function:
        constexpr _FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Compare)
        [with _FIter = gnu_debug::_Safe_iterator<gnu_cxx::
        normal_iterator<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>*,
        vector<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter>,
        allocator<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> > > >,
        debug::vector<unique_ptr<dwarf2_per_cu, dwarf2_per_cu_deleter> >,
        random_access_iterator_tag>; _Tp = section_and_offset; _Compare =
        dwarf2_find_unit(const section_and_offset&,
        dwarf2_per_bfd*)::<lambda(const dwarf2_per_cu_up&, const
        section_and_offset&)>]

    Error: elements in iterator range [first, last) are not partitioned by the
    predicate __comp and value __val.

Knowing all this, is it easy to artificially reproduce the problem by
making create_all_units() reverse the all_units vector, like so:

    // Reverse the all_units vector
    std::reverse (per_objfile->per_bfd->all_units.begin (),
                  per_objfile->per_bfd->all_units.end ());

The fix is to reorder the operations in this way

 - call create_all_units(), to fill the all_units vector by walking
   `.debug_info` and `.debug_types`
 - call create_foreign_type_units_from_debug_names(), which may add more
   items to the all_units vector.
 - call finalize_all_units(), to sort the all_units vector.
 - call the build_and_check_* functions, which is fine now that
   all_units is sorted.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34149
Change-Id: I315f391605af549b55341a167683d2dc6203bcea
Approved-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: fix regexp in gdb.rocm/watchpoint-at-end-of-shader.exp

The following tests fail:

  FAIL: gdb.rocm/watchpoint-at-end-of-shader.exp: precise_memory=on: continue
  FAIL: gdb.rocm/watchpoint-at-end-of-shader.exp: precise_memory=off: continue

The reason is a difference in outputs seen in upstream and downstream
branches.  Fix the regexps to avoid the failures.

Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)

Re: PR 30308 again

Also put in place a testcase, so this (hopefully) won't regress again.

PR 30308 again

Commit 22f8905d9f38 reintroduced pr30308.  This fix resolves equates
safely in the presence of symbol loops by using symbol_equated_to.
Symbols aren't prematurely modified, by copying their value
expressions before i386_intel_simplify does its work.  I figure that
it is safer to do this for all symbols rather than just the particular
case of equates, so the in_equate parameter can disappear.

[gdb/tui] Allow second tui enable if first fails

Commit fb23d7ba4a2 ("[gdb/tui] Handle error in tui_enable") handles a
particular error during tui_enable, but doesn't allow trying to enable TUI
again.

I tried to get this to work, but didn't manage because I didn't understand the
interaction between endwin and the "tui_batch_rendering defer" destructor:
- first endwin restores the shell terminal mode
- then the defer destructor calls doupdate, restoring program terminal mode.

Fix this by checking for tui_active in ~tui_batch_rendering.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/tui] Factor out init_ncurses

Factor out init_ncurses out of tui_enable, and make sure calling it twice is
harmless.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/tui] Factor out require_tui_terminal

I noticed this bit of code in tui_enable:
...
      /* Check required terminal capabilities.  The MinGW port of
 ncurses does have them, but doesn't expose them through "cup".  */
      cap = tigetstr ((char *) "cup");
      if (cap == NULL || cap == (char *) -1 || *cap == '\0')
{
  endwin ();
  delscreen (s);
  error (_("Cannot enable the TUI: "
   "terminal doesn't support cursor addressing [TERM=%s]"),
 gdb_getenv_term ());
}
...

At this point in tui_enable, we need endwin and delscreen to clean up after
newterm, but the check can be done before newterm.

Fix this by factoring out a new function require_tui_terminal, and moving the
code there.

Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

[pre-commit] Bump black to 26.5.1

Ran "pre-commit autoupdate".  No changes in formatting.

[pre-commit] Bump black to 26.5.0

Ran "pre-commit autoupdate".  No changes in formatting.

Automatic date update in version.in

gdb/aarch64: record/replay support for RPRFM, PRFM (reg), PRFUM

The PRFM (register) instruction variant was unsupported. This is added
along with RPRFM and PRFUM.

No testcase has been added as these are hint instructions which don't
modify registers/memory.

The full testsuite was done on aarch64-none-linux-gnu without RPRFM.
The gdb.arch and gdb.reverse tests were run on Shrinkwrap with RPRFM
support.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: add a test to check for Python traits static_assert

The previous two commits added a new type trait which can be used
within a static_assert to check the properties of a struct used by GDB
to implement Python objects.

The previous commit fixed a bug in GDB which this trait check exposed.

This commit adds a new test gdb.gdb/python-traits-check.exp which
checks that every struct in the Python/ directory that inherits from
PyObject, has a suitable static_assert in place.

Adding this test should mean that if someone adds a new Python object
type to GDB, and they forget to add the static_assert, then this test
should give a failure, which should remind them to add the required
static_assert.  The static_assert will then check that their new
struct is compliant.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: fix use of frame_info_ptr within pending_frame_object

The previous commit added a type trait which identifies types that
should not be used within Python objects, that is, types that are not
trivially default constructible.  As a result of this, it was
discovered that pending_frame_object includes a frame_info_ptr field.

The problem with frame_info_ptr is that its constructor registers the
new frame_info_ptr with the global frame_list.  It is by this
registration that invalidation of frame_info_ptr objects is performed.

As Python is written in C, C++ constructors are not called, so when a
pending_frame_object is created the constructor for the nested
frame_info_ptr field is never run, and the frame_info_ptr is never
registered with the global frame_list.  As a result the frame_info_ptr
will never be invalidated if the frame cache is flushed, this can then
lead to problems where we make use of the 'frame_info *' within the
frame_info_ptr, even though it is no longer valid.

In this commit I change the frame_info_ptr within pending_frame_object
to a 'frame_info_ptr *' and allocate the frame_info_ptr object on the
heap, releasing the object, and resetting the point to NULL, when we
are done with it.  As the pending_frame_object only needs to remain
valid for the duration of frame_unwind_python::sniff, the 'new' and
'delete' both performed within the function.

We can now check that a pending_frame_object is valid by checking if
the 'frame_info_ptr *' is NULL or not.  As the frame_info_ptr is
created in a valid state, and the point is set back to NULL when we
are done with it, we no longer need to compare the frame_info_ptr
object itself against NULL.

The remaining changes in this patch are to dereference the
'frame_info_ptr *' in places where we need the actual object.  In some
cases I need to move the dereference later within a function, after a
validity check, in order to avoid dereferencing a NULL pointer.

Finally, I can add the static_assert that guarantees that
pending_frame_object is now safe for allocation by Python.

I discovered this bug while looking at PR gdb/32120.  That bug is
about a user's custom frame unwinder that triggers a flush of the
frame cache during the sniffer phase (the
RemoteTargetConnection.send_packet call switches thread, which
triggers the frame cache flush).  While looking at that bug I noticed
that the frame_info_ptr within the pending_frame_object wasn't being
reset when the frame cache was flushed.  Fixing this does not resolve
the user's issue, but I thought it was still worth tagging this commit
with the bug link.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32120

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: add type traits check for all PyObject sub-classes

All of our custom Python types are created as structs, like this:

  struct some_new_type : public PyObject
  {
    ... various fields ...
  };

Then instances of this struct are created by calling PyObject_New,
either directly within GDB's C++ code, or within Python when a user's
Python script creates an instance of that class.

The problem is that Python is written in C, and PyObject_New doesn't
call any constructors for `some_new_type`, nor for any of the fields
within `some_new_type`.

If `some_new_type` is Plain Old Data (POD), then this is fine.  Or, to
be more C++ specific, if `some_new_type` is trivially default
constructable, then we're fine.

But if a field within `some_new_type` has a non-trivial constructor,
then we're in trouble as that constructor will never be run.

An example of a problematic field type is frame_info_ptr.  The
constructor for this type registers the new object with a central
management object, recording the `this` pointer, using this type within
`some_new_type` will not work as expected; frame invalidation will not
show up within the frame_info_ptr as you might expect.

And so, this type trait exists.  Whenever a struct is created to define
a new Python type we should add a line like:

  static_assert (gdb::is_python_allocatable_v<some_new_type>);

This will fail if any field of `some_new_type` are unsuitable for this
use.

We don't actually check is_trivially_default_constructible here.  Some
types, e.g. ui_file_style::color, have non-trivial (or no default)
constructors, but are still safe to use within `some_new_type` because
their constructors just initialise data fields; there's nothing
"special" that the constructor does that cannot be achieved by
assigning the fields after creation with PyObject_New.

What actually matters is that the type is trivially destructible
(Python won't call C++ destructors, so destructors with side effects,
like deregistering from a list, would be skipped) and trivially
copyable (Python may copy objects with memcpy).  Types like
frame_info_ptr, whose constructors and destructors have side effects
such as registering with a central management object, will be caught
because they are neither trivially destructible nor trivially copyable.
Simple POD types like ui_file_style are trivially destructible and
copyable, so pass this trait.

This commit adds the new type trait, and makes use of it in all cases
but one, pending_frame_object in python/py-unwind.c, has a field of
type frame_info_ptr, which is currently broken.  This will be fixed,
and the static_assert added, in the next commit.

Approved-By: Tom Tromey <tom@tromey.com>

Re: binutils/configure: look for msgpack-c.pc (in addition to msgpack.pc)

Commit 520c7eefed7f results in the following if both msgpack-c and
msgpack are missing.

checking for msgpack-c... no
checking for msgpack... no
configure: error: Package requirements (msgpack) were not met:

Package 'msgpack', required by 'virtual:world', not found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables MSGPACK_CFLAGS
and MSGPACK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make[2]: *** [Makefile:920: config.status] Error 1
make[2]: Leaving directory '/build/gas/all/binutils'
make[1]: *** [Makefile:4123: all-binutils] Error 2

binutils/
* configure.ac <msgpack>: Tell PKG_CHECK_MODULES that errors
will be handled by its caller.
* configure: Regenerate.
bfd/
* bfd-in2.h: Regenerate.

Automatic date update in version.in

Handle DW_AT_encoding on DW_TAG_enumeration_type

A user pointed out a problem when printing certain values from an Ada
enumeration type.  Investigation showed that the problem was that some
enumeration constants were emitted using DW_FORM_data1, and were
incorrectly sign-extended by gdb.

First, this is yet another instance of a general problem with DWARF.
See https://sourceware.org/bugzilla/show_bug.cgi?id=32680 for the
analysis.

Meanwhile, it turns out that GCC implements an extension to handle
this scenario.  In particular, in non-strict mode, it will emit
DW_AT_encoding using either DW_ATE_signed or DW_ATE_unsigned.  This
was done back in 2017 by Pierre-Marie, in support of Ada -- but then
somehow nothing was ever implemented on the gdb side.  For this see
GCC commit f76f096e ("DWARF: add DW_AT_encoding attributes for
DW_TAG_enumeration_type DIEs").

This patch adds the missing code to gdb.  The included test case shows
the bug that was originally reported.  I've also included the snippet
from Pierre-Marie's commit message for good measure.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/python] Use py_{none,notimplemented} more often

Replace:
...
    {
      Py_INCREF (Py_NotImplemented);
      return Py_NotImplemented;
    }
...
with:
...
    return py_notimplemented ().release ();
...

Likewise for py_none.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/python] Use py_{none,false} more often

Do:
...
$ sed -i \
    "s/gdbpy_ref<>::new_reference (Py_False)/py_false ()/" \
    gdb/python/*.{c,h}
...

Likewise for py_none.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/python] Undefine Py_RETURN_{NONE,TRUE,FALSE,NOTIMPLEMENTED}

Now that we've removed all uses of Py_RETURN_{NONE,TRUE,FALSE,NOTIMPLEMENTED},
undefine them to enforce using the refcount-safe wrappers instead.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/python] Remove Py_RETURN_{NONE,TRUE,FALSE,NOTIMPLEMENTED}

Result of:
...
$ sed -i 's/Py_RETURN_NONE/return py_none ().release ()/' gdb/python/*.{c,h}
...
with the changes in py_none reverted.

Likewise for Py_RETURN_TRUE,Py_RETURN_FALSE and Py_RETURN_NOTIMPLEMENTED.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34145

[gdb/python] Introduce py_{none,true,false,notimplemented} functions

I came across this code:
...
   if (c)
     return v;
   else
     Py_RETURN_NONE;
...
and realized I couldn't easily rewrite it into "return c ? v : ...".

Probably something like this would work:
...
  return c ? v : ([] { Py_RETURN_NONE; } ());
...
but it made me wonder if we can get rid of Py_RETURN_NONE.

The only point of it seems to be to increase the reference count on the
Py_None object for older python versions.

Add a refcount-safe wrapper py_none (returning a gdbpy_ref), with the aim of
replacing all uses of Py_RETURN_NONE with "return py_none ().release ()".

Likewise for Py_RETURN_TRUE/Py_RETURN_FALSE/Py_RETURN_NOTIMPLEMENTED.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34145

gdb: remove declaration of deprecated_target_wait_hook

Remove the declaration of deprecated_target_wait_hook; the actual
definition and usage were removed 4 years ago in:

  commit fb85cece22a2cb3c0185e61cfc1323e9c5a6466e
  Date:   Sat Mar 12 13:41:47 2022 +0100

    Replace deprecated_target_wait_hook by observers

There should be no user-visible changes after this commit.

gdb: int to bool conversion in linux-thread-db.c

Some 'int' to 'bool' cleanup in linux-thread-db.c.  There should be no
user visible changes after this commit.

Reviewed-By: Keith Seitz <keiths@redhat.com>

binutils/configure: look for msgpack-c.pc (in addition to msgpack.pc)

msgpack.pc was renamed to msgpack-c.pc in this commit [1].  This means
that we now find both in the wild.  For example Debian Bookworm has
msgpack.pc [2] while Debian Trixie has msgpack-c.pc [3].

Update the check in configure.ac to check for both.  Nothing in the code
needs to change.

[1] https://github.com/msgpack/msgpack-c/commit/01f3d24feee3a06b2a83c89b54fd0ec778d14610
[2] https://packages.debian.org/bookworm/amd64/libmsgpack-dev/filelist
[3] https://packages.debian.org/trixie/amd64/libmsgpack-c-dev/filelist

aarch64: Add qualifier checks to aarch64-gen

Add checks to verify that all qualifier sequences have the correct
length.

aarch64: Add new qualifier AARCH64_OPND_QLF_UNUSED

Replace QLF_NIL with QLF_UNUSED for qualifier sequence list padding.
This splits apart distinct qualifier meanings, and simplifies detection
of empty qualifier sequences.

aarch64: Remove F_STRICT

With the introduction of AARCH64_OPND_QLF_UNKNOWN, the F_STRICT flag is
no longer needed and can be deleted.

aarch64: Add new qualifier ARCH64_OPND_QLF_UNKNOWN

Some uses of AARCH64_OPND_QLF_NIL actually represent an unknown operand
qualifier.  The F_STRICT flag was added to disable the wild card
behaviour for most SVE instructions, but this just makes the code less
consistent and more confusing.

Add a new qualifer to indicate that the real qualifier is currently
unknown, and use this in any place where we need the wildcard behaviour
(and in a few other places where UNKNOWN is more descriptive than NIL).

For consistency (and as an extra check during development), change the
default qualifier value during parsing to AARCH64_OPND_QLF_ERR, and add
explicit qualifier assignments to each non-failure code path.

aarch64: Return QLF_ERR for error conditions

In vectype_to_qualifier and get_qualifier_from_partial_encoding, return
AARCH64_OPND_QLF_ERR instead of AARCH64_OPND_QLF_NIL to indicate an
error condition.

aarch64: Add QLF_ERR to aarch64_opnd_qualifiers

Add an entry to aarch64_opnd_qualifiers for AARCH64_OPND_QLF_ERR.  This
should never be used (otherwise we would previously have had
out-of-bounds memory accesses), but it makes the array length match the
enum length, and might be slightly more robust.

aarch64: Add explicit all-nil qualifers to opcode table

AARCH64_OPND_QLF_NIL will soon have a nonzero enum value, so make this
value explicit in qualifier sequences.

aarch64: Append explicit NILs to qualifier sequences

For some opcodes, the NIL qualifier on the final operand was set
implicitly via empty initialisation of the unspecified entries in the
list of qualifier sequences.  Make this assignment explicit, to avoid
depending on the numerical value of AARCH64_OPND_QLF_NIL.

aarch64: Remove excess operand qualifiers

Some instructions had qualifier sequences that were longer than the
number of operands.  Remove the unused qualifiers.

aarch64: Make FPIMM0 qualifiers consistent

Two entries in the opcode table used QLF_S_H for the FPIMM0 operand
instead of the QLF_NIL operand used elsewhere.  There is no good reason
for this inconsistency, so change them to use QLF_NIL as well.

aarch64: Fix qualifier sequences for cinc/cinv/cneg

The three-operand cinc/cinv/cneg instructions were incorrectly specified
with the same qualifier sequences as the four-operand variants, which
resulted in their third operand having an incorrect qualifier specified.
This works fine while AARCH64_OPND_QLF_NIL is treated as a wildcard, but
will break when that behaviour is removed.

Fix this by using QL_R2NIL instead.

aarch64: Fix ldst_lo12_determine_real_reloc_type

Add fallback handling for an invalid choice of opd0_qlf, instead of
hitting an assert when trying to use X registers in byte or half
instructions.

Additionally, simplify the code by inlining the relevant parts of
aarch64_get_expected_qualifer, and by deducing the array index directly
from the qualifier enum values (instead of looking up the element size
and computing its log).

This makes aarch64_get_expected_qualifier unused, so remove it.

aarch64: Add F_REQUIRES_SP and eliminate QLF_SP and QLF_WSP

Add a new opcode flag F_REQUIRES_SP and use that to enforce the
requirement for at least one SP operand in the mov (to/from SP) opcode.

This requirement was the only reason for the existence of the QLF_SP and
QLF_WSP qualifiers.  Delete them, and remove the confusing code that
would switch between SP and non-SP qualifiers in the middle of qualifier
matching.

aarch64: Add an assert to inherent_reg_qualifier

The default case isn't useful and is currently unreachable, so add an
assert instead.

aarch64: Replace inst.base.operands[i]. with info->

In parse_operands, we have *info = &inst.base.operands[i], so let's use
the shorter form wherever possible.

aarch64: Remove dead qualifier initialisation

aarch64: Remove unnecessary temporary variables

aarch64: Make comparison to QLF_NIL more explicit

This removes the assumption that AARCH64_OPND_QLF_NIL is zero.