Add optional filename argument to the linker's --stats option, allowing extra resource use information to be reported.

Add gdb.base/set-solib-absolute-prefix.exp

Compile a 32-bit x86 executable and then stop within a system call.
Change the sysroot to a non-existent directory, GDB should try (and
fail) to reload the currently loaded shared libraries.  However, GDB
should retain the symbols for the vDSO library as that is not loaded
from the file system.

Check the backtrace to ensure that the __kernel_vsyscall symbol is
still in the backtrace, this indicates GDB still has the vDSO
symbols available.

This test was present in Fedora for a long time and was
originally written by Jan Kratochvil for this fix
829a902da291e72ad17e8c44fa8d9ead3db41b1f.

Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Automatic date update in version.in

gdb: move addrmap::relocate method to addrmap_fixed

The relocate method of addrmap is unnecessarily virtual.  Only
addrmap_fixed provides a meaningful implementation.  Move the method to
addrmap_fixed only and make it non-virtual.

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

[gdb/contrib] Support gdb in codespell section of setup.cfg

Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg,
specifically adding files in the skip line.

This allows us to run codespell from the command line on the gdb dir:
...
$ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l
1665
...
without running into warnings in generated files.

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

Update cooked_index comment

This updates the cooked_index comment with some notes about object
lifetimes, in an attempt to make navigating this code a bit simpler.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add cooked_index_worker::done_reading

The two readers currently using cooked_index_worker shared some code.
This patch factors this out into a new "done_reading" method.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Remove cooked_index_worker::result_type

cooked_index_worker::result_type is an ad hoc tuple type used for
transferring data between phases of the indexer.  It's a bit unwieldy
and another patch I'm working on would be somewhat nicer without it.

This patch removes the type.  Now cooked_index_ephemeral objects are
transferred instead, which is handy because they already hold the
needed state.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add addrmap_mutable::clear

It was convenient to add a 'clear' method to addrmap_mutable.  The
cleanest way to do this was to change the class to lazily initialize
its 'tree' member.  This also makes addrmap_mutable::operator= a bit
less weird.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Update comments from moved methods

This updates the "See xyz.h" comments for all the methods that were
moved earlier in this series.  Perhaps I should have removed them
instead.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Move cooked_index_worker to cooked-index-worker.[ch]

This moves the cooked_index_worker class to cooked-index-worker.[ch].

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Change includes in cooked-index-worker.h

This changes cooked-index-worker.h to include the new header files.
This breaks the circular dependency that would otherwise be introduced
in the next patch.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Move cooked_index_shard to new files

This moves cooked_index_shard to a couple of new files,
dwarf2/cooked-index-shard.[ch].  The rationale is the same as the
previous patch: cooked-index.h had to be split to enable other
cleanups.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Move cooked_index_entry to new files

This moves cooked_index_entry and some related helper code to a couple
of new files, dwarf2/cooked-index-entry.[ch].

The main rationale for this is that in order to finish this series and
remove "cooked_index_worker::result_type", I had to split
cooked-index.h into multiple parts to avoid circular includes.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Make language_requires_canonicalization 'static'

language_requires_canonicalization is only called from cooked-index.c,
so mark it as static.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Rename cooked_index_storage

This renames cooked_index_storage to cooked_index_worker_result,
making its function more clear.  It also updates the class comment to
as well.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Rename cooked-index-storage.[ch]

A discussion with Simon made me realize that cooked_index_storage
isn't a very clear name, especially now that it's escaped from read.c.
While it does provide some storage (I guess any object does in a
sense), it is really a helper for cooked_index_worker -- a temporary
object that is destroyed after reading has completed.

This patch renames this file.  Later patches will rename the class and
move cooked_index_worker here, something I think is reasonable given
that cooked_index_storage is really something of a helper class for
cooked_index_worker.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

PR32829, SEGV on objdump function debug_type_samep

u.kenum is always non-NULL, see debug_make_enum_type.

PR 32829
* debug.c (debug_type_samep): Correct incomplete enum test.
(debug_write_type): Remove dead code.

ubsan: nds32 undefined shift

Avoid implementation defined behaviour right shift of negative values,
and undefined behaviour left shift of negative values.  While this
change might give different results in the top bit of a bfd_vma
(rightshift is 1), that doesn't matter as only the bottom 8 bits of
the relocation are used.

* elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Calculate relocation
using a bfd_vma type.

Formatting fixes for elf-attrs.c

Check gnatmake version in gnat_version_compare

Tom de Vries pointed out that my earlier change to
gnat_version_compare made it actually test gcc's version -- not
gnat's.

This patch changes gnat_version_compare to examine gnatmake's version,
while preserving the nicer API.

Approved-By: Tom de Vries <tdevries@suse.de>

binutils/testsuite: don't tail the same input and output file

The output file could be created before the input is gathered by tail,
erasing the later before it's being proceeded.

This happened on rare cases when performing remote tests on
Ubuntu 24.04.

binutils/testsuite: move objdump test output into tmpdir

"objdump.out" is a testsuite trace and thus should be created within the
tmpdir.

Automatic date update in version.in

testsuite: fix is_aarch32_target

Commit

   c221b2f77080 Testsuite: Add gdb_can_simple_compile

changed the source file name extension of the test program from .s to .c
resulting in compile fails.  This, in turn, causes is_aarch32_target
checks to fail.

Change the test source from an assembly program to a C program using
inline assembly.

is_amd64_regs_target had a similar problem, which was fixed by commit

    224d30d39365 testsuite: fix is_amd64_regs_target

This fix — and commit message — are mostly copied from it.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbserver: Add support for MicroBlaze host microblaze*-*-linux*

Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com>
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Signed-off-by: Michael Eager <eager@eagercon.com>

[gdb/record] Make enum gdb_syscall value names consistent

In enum gdb_syscall, there are 3 entries that do not have the gdb_sys_ prefix
...
$ grep gdb_old_ gdb/linux-record.h
  gdb_old_select = 82,
  gdb_old_readdir = 89,
  gdb_old_mmap = 90,
...
like all the other entries:
...
  gdb_sys_restart_syscall = 0,
  gdb_sys_exit = 1,
  gdb_sys_fork = 2,
  gdb_sys_read = 3,
...

The three correspond to these entries in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number>  <abi>   <name>     <entry point>      [<compat entry point> [noreturn]]
82        i386    select     sys_old_select     compat_sys_old_select
89        i386    readdir    sys_old_readdir    compat_sys_old_readdir
90        i386    mmap       sys_old_mmap       compat_sys_ia32_mmap
...

As we can see, the enum uses the entry point name, but without the sys_
prefix.

There doesn't seem to be a good reason for this.

There's another enum value:
...
  gdb_sys_old_getrlimit = 76,
...
corresponding to:
...
76        i386    getrlimit  sys_old_getrlimit  compat_sys_old_getrlimit
...
where we do use the sys_ prefix.

Fix this by consistenly using the gdb_sys_ prefix in enum gdb_syscall.

No functional changes.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/contrib] Remove spellcheck.sh

Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and
associated file gdb/contrib/common-misspellings.txt.

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

[gdb] Check strpbrk against nullptr

In noticed two occurrences of "if (strpbrk (...))".

Fix this style issue by checking against nullptr.

gdbsupport/common-inferior.c: Fix mingw build

A recent change (512ca2fca4b "gdb: split up
construct_inferior_arguments") introduced a build failure for mingw:

      CXX      common-inferior.o
    .../gdb/gdbsupport/common-inferior.cc: In function ‘std::string escape_characters(const char*, const char*)’:
    .../gdb/gdbsupport/common-inferior.cc:62:20: error: ‘argv’ was not declared in this scope; did you mean ‘arg’?
       62 |       if (strpbrk (argv[i], special))
          |                    ^~~~
          |                    arg
    .../gdb/gdbsupport/common-inferior.cc:62:25: error: ‘i’ was not declared in this scope
       62 |       if (strpbrk (argv[i], special))
          |                         ^

This patch fixes that.

Change-Id: I07ade607bc4516627b433085b07d9d198d8e4b4a
Approved-By: Tom de Vries <tdevries@suse.de>

ld/PE: Add another mingw UCRT library name to the autoexport exclusion list

Since 2020, mingw-w64 provides a C runtime import library variant
named "libucrtapp" too, exclude this one from autoexports like
the others.

Signed-off-by: Martin Storsjö <martin@martin.st>

[pre-commit] Add codespell hook

Add a pre-commit codespell hook for directories gdbsupport and gdbserver,
which are codespell-clean:
...
$ pre-commit run codespell --all-files
codespell................................................................Passed
...

A non-trivial question is where the codespell configuration goes.

Currently we have codespell sections in gdbsupport/setup.cfg and
gdbserver/setup.cfg, but codespell doesn't automatically use those because the
pre-commit hook runs codespell at the root of the repository.

A solution would be to replace those 2 setup.cfg files with a setup.cfg in the
root of the repository.  Not ideal because generally we try to avoid adding
files related to subdirectories at the root.

Another solution would be to add two codespell hooks, one using
--config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and
add a third one once we start supporting gdb.  Not ideal because it creates
duplication, but certainly possible.

I went with the following solution: a setup.cfg file in gdb/contrib (alongside
codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport.

So, what can this new setup do for us?  Let's demonstrate by simulating a typo:
...
$ echo "/* aways */" >> gdbsupport/agent.cc
...

We can check unstaged changes before committing:
...
$ pre-commit run codespell --all-files
codespell................................................................Failed
- hook id: codespell
- exit code: 65

gdbsupport/agent.cc:282: aways ==> always, away
...

Likewise, staged changes (no need for the --all-files):
...
$ git add gdbsupport/agent.cc
$ pre-commit run codespell
codespell................................................................Failed
- hook id: codespell
- exit code: 65

gdbsupport/agent.cc:282: aways ==> always, away
...

Or we can try to commit, and run into the codespell failure:
...
$ git commit -a
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell................................................................Failed
- hook id: codespell
- exit code: 65

gdbsupport/agent.cc:282: aways ==> always, away

check-include-guards.................................(no files to check)Skipped
...
which makes the commit fail.

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

Automatic date update in version.in

[gdb/tdep] Fix mmap syscall mapping

There are a few spots where an mmap system call is mapped onto enum
gdb_syscall value gdb_sys_mmap2.

Strictly speaking, this is incorrect.

Fix this by mapping to enum gdb_syscall value gdb_old_mmap instead.

No functional changes: both gdb_old_mmap and gdb_sys_mmap2 are handled the
same in record_linux_system_call.

Tested by rebuilding on x86_64-linux.

[gdb] Skip selftest with warning

With the selftest register_name, we run into a few warning:
...
$ gdb -q -batch -ex "maint selftest register_name" 2>&1 \
    | grep -B1 warning:
Running selftest register_name::m68hc11.
warning: No frame soft register found in the symbol table.
--
Running selftest register_name::m68hc12.
warning: No frame soft register found in the symbol table.
--
Running selftest register_name::m68hc12:HCS12.
warning: No frame soft register found in the symbol table.
...

We already filter out these architectures in other selftests because of the
same warning.

Do the same in this selftest.

Tested on x86_64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>

Automatic date update in version.in

gdb: remove disable_breakpoints_in_shlibs function

I think there is a problem with the disable_breakpoints_in_shlibs
function: it can disable breakpoint locations without calling
notify_breakpoint_modified.  This means that the Python API's
breakpoint_modified event will not trigger, nor will the MI send a
breakpoint modified event.

I started looking at disable_breakpoints_in_shlibs because of an
earlier commit:

  commit 8c48ec7a6160aed0d1126c623443935e4435cd41
  Date:   Thu Aug 29 12:34:15 2024 +0100

      gdb: handle dprintf breakpoints when unloading a shared library

Currently disable_breakpoints_in_shlibs is only called from one
location, clear_solib in solib.c.  clear_solib also calls
notify_solib_unloaded for every solib in the program_space of
interest, and notify_solib_unloaded will call
disable_breakpoints_in_unloaded_shlib via the solib_unloaded
observer.  These two function, disable_breakpoints_in_shlibs and
disable_breakpoints_in_unloaded_shlib are very similar in what they
do.

I think that we can remove the disable_breakpoints_in_shlibs call, and
instead, tweak how we call disable_breakpoints_in_unloaded_shlib in
order to get the same end result, except that, after this change, we
will call notify_breakpoint_modified, which means the Python API event
will trigger, and the MI events will be emitted.

All that disable_breakpoints_in_shlibs does is disable some
breakpoints.

Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the
same set of breakpoints, call notify_breakpoint_modified, and
then (for some breakpoint types) print a message telling the user that
the breakpoint has been disabled.  However, this function will ignore
any breakpoints that are already disabled.

As disable_breakpoints_in_shlibs disables the same set of breakpoints,
the result of the current code is that disable_breakpoints_in_shlibs
serves only to prevent the notify_breakpoint_modified call, which I
think is wrong, and to prevent the user message being printed, which I
think is reasonable.

If we remove the disable_breakpoints_in_shlibs call without making any
additional changes, then we start to see some message printed in cases
like this:

  (gdb) start
  The program being debugged has been started already.
  Start it from the beginning? (y or n) y
  warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so"
  Temporary breakpoint 3 at 0x40113e: file test.c, line 9.
  Starting program: /tmp/shared-lib-test/test.x

Notice the 'warning:' line, which is new.  I think this is confusing
because, in most cases the breakpoint will be enabled again by the
time the inferior reaches `main` and stops.

In the future I'm interested in exploring if GDB could be smarter
about when to print these 'Temporarily disabling breakpoints ...'
messages so that if the 'start' command does mean a breakpoint is left
disabled, then the user would be informed.  However, I don't propose
doing that work immediately, and certainly not in this commit.  For
now, my intention is to leave things as they are right now, GDB
doesn't warn about disabling breakpoints during an inferior re-start.

To achieve this I think we need to pass a new argument to
disable_breakpoints_in_unloaded_shlib which controls whether we should
print a message about the breakpoint being disabled or not.  With this
added we can now silence the warning when the inferior is
restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called
from clear_solib), but keep the warning for cases like stepping over a
dlclose() call in the inferior.

After this commit, GDB now emits breakpoint modified events (in Python
and/or MI) when a breakpoint is disabled as a result of all shared
libraries being unloaded.  This will be visible in two places that I
can thing of, the 'nosharedlibrary' command, and when an inferior is
restarted.

x86: Add {noimm8s} pseudo prefix

Instruction templates with only sign-extended 8-bit immediate operand
also have a second template with full-operand-size immediate operand
under a different opcode.  Add {noimm8s} pseudo prefix to exclude
templates with only sign-extended 8-bit immediate operand.

gas/

PR gas/32811
* config/tc-i386.c (pseudo_prefixes): Add no_imm8s.
(operand_size_match): Return false for templates with only sign-
extended 8-bit immediate operand if {noimm8s} is used.
(parse_insn): Handle Prefix_NoImm8s.
* doc/c-i386.texi: Document {noimm8s}.
* testsuite/gas/i386/pseudos.s: Add tests for {noimm8s}.
* testsuite/gas/i386/x86-64-pseudos.s: Likewise.
* testsuite/gas/i386/pseudos.d: Updated.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.

opcodes/

PR gas/32811
* opcodes/i386-opc.h (Prefix_NoImm8s): New.
* i386-opc.tbl: Add {noimm8s} pseudo prefix.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Likewise.

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

gprof: Always compile tests with -g

Always compile gprof testsuite with -g for line number info checked by
tst-gmon-gprof-l.sh.

PR gprof/32779
* testsuite/Makefile.am (GPROF_FLAGS): Add -g.
(COMPILE): Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS)".
(LINK) Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS) $(AM_LDFLAGS)
$(LDFLAGS) -o $@".
* testsuite/Makefile.in: Regenerated.

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

Automatic date update in version.in

gdb: reduce breakpoint-modified events for dprintf b/p

Consider this backtrace within GDB:

  #0  notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083
  #1  0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523
  #2  0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641
  #3  0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476
  #4  0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298

Whenever breakpoint_re_set is called we re-build the commands that the
dprintf b/p will execute and store these into the breakpoint.  The
commands are re-built in update_dprintf_command_list and stored into
the breakpoint object in breakpoint_set_commands.

Now sometimes these commands can change, dprintf_breakpoint::re_set
explains one case where this can occur, and I'm sure there must be
others.  But in most cases the commands we recalculate will not
change.  This means that the breakpoint modified event which is
emitted from breakpoint_set_commands is redundant.

This commit aims to eliminate the redundant breakpoint modified events
for dprintf breakpoints.  This is done by adding a commands_equal call
to the start of breakpoint_set_commands.

The commands_equal function is a new function which compares two
command_line objects and returns true if they are identical.  Using
this function we can check if the new commands passed to
breakpoint_set_commands are identical to the breakpoint's existing
commands.  If the new commands are equal then we don't need to change
anything on the new breakpoint, and the breakpoint modified event can
be skipped.

The test for this commit stops at a dlopen() call in the inferior,
sets up a dprintf breakpoint, then uses 'next' to step over the
dlopen() call.  When the library loads GDB call breakpoint_re_set,
which calls dprintf_breakpoint::re_set.  But in this case we don't
expect the calculated command string to change, so we don't expect to
see the breakpoint modified event.

Fix gstack issues

With commit fb2ded33c1e519659743047ed7817166545b6d91, I added
Fedora's gstack script to gdb.  Some issues have arisen since
then, and this patch addresses those issues:

. As Sam James recently noted[1], PKGVERSION and VERSION
  need to be quoted.
. A Fedora user reported the misuse of --readnever, which
  causes gstack to omit filename and line number information in the
  backtrace[Red Hat BZ 2354997].

[1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997

x86: Pass $NOPIE_LDFLAGS to undefined weak tests

Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by some of the tests.  Therefore link the PDE test programs with
$NOPIE_LDFLAGS to disable PIE.

This complements commit a7eaf017f959 ("Use NOPIE_CFLAGS and
NOPIE_LDFLAGS to disable PIE").

ld/testsuite/
PR ld/21090
* ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to
disable PIE for the non-PIE versions of the test.

Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF visibility tests

Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test.  Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.

Commit 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added
$NOPIE_CFLAGS when compiling sh1np.o and sh2np.o.  It missed to add it
to mainnp.o.

ld/testsuite/
PR ld/21090
* ld-vsb/vsb.exp (visibility_test): Add support for optional
ldflags argument and use it when linking the test program.
(mainnp.o): Compile with $NOPIE_CFLAGS.
(vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS.

Fixes: 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to even more ELF shared tests

Some distributions configure GCC with --enable-default-pie, so that it
defaults to compile with -fPIE and link with -pie, which is unexpected
by the test.  Therefore compile the non-PIC sources with $NOPIE_CFLAGS
and link the test programs with $NOPIE_LDFLAGS.

Commit 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF
tests") added $NOPIE_CFLAGS when compiling sh1np.o.  It missed to add it
to sh2np.o and mainnp.o.

ld/testsuite/
PR ld/21090
* ld-shared/shared.exp (shared_test): Add support for optional
ldflags argument and use it when linking the test program.
(sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS.
(shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS.

Fixes: 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests")
Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr21964-4

Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on
Fedora 41.  The reason is that GCC on Ubuntu is configured with
--enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which causes the test to erroneously fail.

ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and
link with $NOPIE_LDFLAGS.

Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr19719

Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41
but not on Ubuntu 24.10.  The reason is that GCC on Ubuntu is configured
with --enable-default-pie, so that it defaults to compile with -fPIE
and link with -pie, which hides the test fail.

ld/testsuite/
PR ld/21090
* ld-elf/shared.exp: Compile pr19719 (non-PIE) with
$NOPIE_CFLAGS and link with $NOPIE_LDFLAGS.

Bug: https://sourceware.org/PR21090
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

RISC-V: Don't show support for 1.9.1 priv spec

The privileged spec 1.9.1 support was removed since binutils 2.43. The
linker only recognizes it and then reports a warning that it may
conflict with other spec versions.

While the support is removed, binutils should still recognize it, but it
shouldn't be exposed to the user in `disassember-options` help.

Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>

doc/riscv: Add description of disassembler options

Up to this point, no mention of RISC-V-specific disassembler options was
mentioned in binutils documentation. This patch includes description for
all of the currently supported options.

Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>

Automatic date update in version.in

gdb: Fix assertion failure when inline frame #0 is duplicated

Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
the following incorrect backtrace:

  #0  inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
  #1  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
  #2  0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
  #3  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1

The expected output, which we get with `bt`, is:

  #0  inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
  #1  normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1

The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
frame ids having already been computed and stashed.  Unlike other
frames, frame #0's id does not get computed immediately.

The test passes with `bt` because when applying python frame filters,
the call to `bootstrap_python_frame_filters` happens to compute the id
of frame #0.  When `get_prev_frame_maybe_check_cycle` later tries to
stash frame #2's id, the cycle is detected.

The test fails with `bt -no-filters` because frame #0's id has not been
stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
frame #2's id which succeeds and the cycle is only detected later when
trying to stash frame #4's id.  Doing `stepi` after the incorrect
backtrace would then trigger an assertion failure when trying to stash
frame #0's id because it is a duplicate of #2's already stashed id.

In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
compute and stash its frame id before returning the previous frame.
This ensures that the id of inline frame 0 has been stashed before
`get_prev_frame_maybe_check_cycle` is called on older frames.

The test case has been updated to run both `bt` and `bt -no-filters`.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>

[gdb/contrib] Drop two words from codespell-ignore-words.txt

Tom Tromey mentioned [1] that the words "invokable" and "useable"
present in codespell-ignore-words.txt should be dropped.

Do so and fix the following typos:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
gdbsupport/common-debug.h:218: invokable ==> invocable
gdbsupport/event-loop.cc:84: useable ==> usable
...

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html

[gdb/contrib] Add SME to codespell-ignore-words.txt

Ignore the following codespell detection:
...
$ codespell --config gdbserver/setup.cfg gdbserver
gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS
...
by adding SME to codespell-ignore-words.txt.

[gdbserver] Fix typo in tracepoint.cc

Fix a typo:
...
$ codespell --config gdbserver/setup.cfg gdbserver/tracepoint.cc
gdbserver/tracepoint.cc:951: mistakingly ==> mistakenly
...

[gdbsupport] Ignore pathc in codespell check in gdb_tilde_expand.cc

Ignore the following codespell detections:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch
gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch
...
by adding codespell:ignore comments.

[gdbsupport] Fix a typo in common-debug.h

Fix a typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h
gdbsupport/common-debug.h:109: re-used ==> reused
...

gdb/dap - Add CompletionsRequest

Use GDB/MI command "-complete" to implement.

Co-authored-by: Simon Farre <simon.farre.cx@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31140
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp

In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run
into:
...
(gdb) inferior 2
[Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)]
[Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running)
(gdb) print global_var = 555
$1 = 555
(gdb) print global_var
$2 = 556
(gdb) FAIL: $exp: all-stop: access mem \
  (print global_var after writing, inf=2, iter=1)
...

I managed to reproduce this on current trunk using a reproducer patch (posted
in the PR).

The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix
gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced
an increment of global_var at the start of main.

This created a race between:
- gdb modifying global_var, and
- the inferior modifying global_var.

Fix this by:
- adding a new empty function setup_done,
- adding a call to setup_done after the increment of global_var, and
- rather than running to main, running to setup_done.

Tested on x86_64-linux.

PR testsuite/32822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822

x86: Remove AVX10.2 256 bit rounding support

Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit
rounding is not that useful because we currently have rounding feature
directly on E-core now and no need to use 256-bit rounding as somehow
a workaround. This patch will remove all the support and backport to
Binutils 2.44.

gas/ChangeLog:

* NEWS: Mention support removal.
* config/tc-i386.c (build_evex_prefix): Remove U bit encode.
(check_VecOperands): Remove ymm check for rounding.
(s_insn): Revise .insn comment.
* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm
rounding related test.
* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/evex.d: Ditto.
* testsuite/gas/i386/evex.s: Ditto.
* testsuite/gas/i386/i386.exp: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-evex.d: Ditto.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.l: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.s: Removed.
* testsuite/gas/i386/avx10_2-rounding.d: Removed.
* testsuite/gas/i386/avx10_2-rounding.s: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed.

opcodes/ChangeLog:

* i386-dis.c (struct instr_info): Remove U bit.
(get_valid_dis386): Roll back to APX condition.
* i386-opc.tbl: Remove ymm rounding support.
* i386-tbl.h: Regenerated.

Automatic date update in version.in

gdb/testsuite: Force DWARF debuginfo where applicable in AIX systems

In the AIX systems available for testing in the gcc compile farm, the
default debug information format is stabs. This is a problem for many
reasons, mainly that stabs is not as complete as dwarf and stabs is
being deprecated in the next release. In the current state, we have:
PASS: 39798
FAIL: 7405
When running these tests, I unfortunately didn't have the foresight to
save the number of unsupported and untested cases.

To improve testing there, this patch changes the gdb_compile TCL proc, so
that if we're running tests in AIX, we requested debug info, and we
haven't explicitly asked for some debuginfo format, gdb_compile will add
-gdwarf to the compilation line, forcing DWARF to be used. After this
patch, we get:
PASS: 74548
FAIL: 5963

So not only do we have fewer failures, there are tens of thousands of
tests that are no longer skipped.

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

ld: Correct test pr19719 naming mix-up

The suffix "defined/undefined" in the ld test pr19719 name specifies
whether weak fun() is defined or undefined is mixed up.

The test builds an executable and a shared library. The latter in two
flavors, one with weak fun() defined (libpr19719a.so, "defined") and
one without weak fun() defined (libpr19719b.so, "undefined").

The first "Run $exe fun [...]" invocation uses libpr19719b.so as
libpr19719.so, which is build from dummy.c, which does not define fun.
Thus fun is undefined during this test run.

The second "Run $exe fun [...]" invocation uses libpr19719a.so as
libpr19719.so, which is build from pr19719d.c, which does define fun.
Thus fun is defined during this test run.

Correct the test naming mix-up accordingly.

ld/testsuite/
* ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming
mix-up of when weak fun is un-/defined.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>

gdb: add configure option to disable compile

GDB's compile subsystem is deeply tied to GDB's ability to understand
DWARF. A future patch will add the option to disable DWARF at configure
time, but for that to work, the compile subsystem will need to be
entirely disabled as well, so this patch adds that possibility.

I also think there is motive for a security conscious user to disable
compile for it's own sake. Considering that the code is quite
unmaintained, and depends on an equally unmaintained gcc plugin, there
is a case to be made that this is an unnecessary increase in the attack
surface if a user knows they won't use the subsystem. Additionally, this
can make compilation slightly faster and the final binary is around 3Mb
smaller. But these are all secondary to the main goal of being able to
disable dwarf at configure time.

To be able to achieve optional compilation, some of the code that
interfaces with compile had to be changed. All parts that directly
called compile things have been wrapped by ifdefs checking for compile
support.  The file compile/compile.c has been setup in a similar way to
how python's and guile's main file has been setup, still being compiled
but only for with placeholder command.

Finally, to avoid several new errors, a new TCL proc was introduced to
gdb.exp, allow_compile_tests, which checks if the "compile" command is
recognized before the inferior is started and otherwise skips the compile
tests. All tests in the gdb.compile subfolder have been updated to use
that, and the test gdb.base/filename-completion also uses this. The proc
skip_compile_feature_tests to recognize when the subsystem has been
disabled at compile time.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: Remove compile-related attributes from struct language

The following patch will add a configure option to disable the compile
subsystem at compilation time. To do that, nearly all code that
interfaces with compile should be confined to the compile sub-folder.

This commit is the first step, removing the compile-related method from
the language struct and adding 2 new functions to compile.c that do the
same job in a slightly different way. Adding things to the language
struct is a more extendable way to add support for languages, but
considering compile is quite bit-rotted and questionably supported, I
don't think it will be extended any time soon, and using ifdefs to
handle disabling compile with configure felt like a messier solution.

There should be no visible changes after this commit.

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

gdb/dwarf: use reference in cutu_reader::cutu_reader interface

Change some parameters to be references instead of pointers, when the
value must not be nullptr.  I'd like to do this more of this kind of
change, but I have to limit the scope of the change, otherwise there's
just no end (and some local variables could also be turned into
references).  So for now, just do it the cutu_reader constructors.

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

gdb/dwarf: update comment of cutu_reader::cutu_reader (the DWO variant)

The comment on this constructor is really outdated.  Update it to better
reflect the reality today.

I'd eventually like to change this cutu_reader constructor not to use
dwarf2_per_cu, because it seems like an abuse of dwarf2_per_cu just to
pass 3 values.  But for now, just document the existing behavior.

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

gdb/dwarf: remove redundant read of dwo_name

lookup_dwo_unit receives the name of the DWO unit to look up, as read
from the DW_AT_dwo_name attribute of the skeleton DIE.  But then, it
doesn't use it:

    /* Yeah, we look dwo_name up again, but it simplifies the code.  */
    dwo_name = dwarf2_dwo_name (comp_unit_die, cu);

Perhaps this comment made sense at some point, but with the code we have
today, I don't understand it.  It should be fine to use the name passed
as a parameter, which the caller also obtained by calling
dwarf2_dwo_name.

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

LoongArch: Fix disassembly option parsing stopping at the first option

Turns out the return value of parse_loongarch_dis_option acts as an
error code, and previously the function always signified failure with
a non-zero return value, making only the first disassembly option get
to take effect.

Fix by adding the missing `return 0`'s to the two success code paths.

Signed-off-by: WANG Xuerui <git@xen0n.name>

ld: Support RELRO in aarch64-elf target

Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so
enable `-z relro` and related features.  Make aarch64-elf match.
There is no reason to think that a "generic ELF" target should
have any particular set of features disabled.

RISC-V: add Smrnmi 1.0 instruction support

Add instruction `mnret' support

Ref:
https://github.com/riscv/riscv-isa-manual/blob/bb8b9127f81965eeff2d150c211d1c89376591c4/src/rnmi.adoc
https://github.com/riscv/riscv-opcodes/blob/946eb673874b3a0f2474d1424dc28bc7ee53c306/extensions/rv_smrnmi

bfd/ChangeLog:
    * elfxx-riscv.c: Add new Smrnmi instruction class handling

gas/ChangeLog:
    * testsuite/gas/riscv/smrnmi.s: New test for mnret
    * testsuite/gas/riscv/rmrnmi.d: Likewise

include/ChangeLog:
    * opcode/ricsv-opc.h: Add MATCH_MNRET, MASK_MNRET
    * opcode/riscv.h: Add new instruction class

opcodes/ChangeLog:
    * riscv-opc.c: Add `mnret' instruction

Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>

Automatic date update in version.in

gdb/dwarf: use std::equal_range in cooked_index_shard::find

Looking at `cooked_index_shard::find`, I thought that we could make a
small optimization: when finding the upper bound, we already know the
lower bound.  And we know that the upper bound is >= the lower bound.
So we could pass `lower` as the first argument of the `std::upper_bound`
call to cut the part of the search space that is below `lower`.

It then occured to me that what we do is basically what
`std::equal_range` is for, so why not use it.  Implementations of
`std::equal_range` are likely do to things as efficiently as possible.

Unfortunately, because `cooked_index_entry::compare` is sensitive to the
order of its parameters, we need to provide two different comparison
functions (just like we do know, to the lower_bound and upper_bound
calls).  But I think that the use of equal_range makes it clear what the
intent of the code is.

Regression tested using the various DWARF target boards on Debian 12.

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

gdb/dwarf: remove unnecessary comparison in cooked_index_entry::compare

I believe that the `(mode == MATCH && a == munge ('<'))` part of the
condition is unnecesary.  Or perhaps I don't understand the algorithm.

The use of "munge" above effectively makes it so that the template
portion of names is completely ignored for the sake of the comparison.

Then, in the condition, this:

    a == munge ('<')

is functionally equivalent to

    a == '\0'

If `a` is indeed '\0', and `b` is also '\0', then we would have taken
the earlier branch:

    if (a == b)
      return 0;

If `b` is not '\0', then we won't take this branch and we'll go into the
final comparison:

    return a < b ? -1 : 1;

So, as far as I can see, there is no case where `mode == MATCH`, where
we're going to use this special `return 0`.

Regression tested using the various DWARF target boards on Debian 12.

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

Delete the ARM sub-directory of the SIM directory.

Automatic date update in version.in

gdb/dwarf: move CU check up in cutu_reader::read_cutu_die_from_dwo

We have this pattern of check in multiple places:

    /* Skip dummy compilation units.  */
    if (m_info_ptr >= begin_info_ptr + this_cu->length ()
        || peek_abbrev_code (abfd, m_info_ptr) == 0)
      m_dummy_p = true;

In all places except one (read_cutu_die_from_dwo), this is done after
reading the unit header but before potentially reading the first DIE.
The effect is that we consider dummy units that have no DIE at all.
Either the "data" portion of the unit (the portion after the header) has
a size of zero, or the first abbrev code is 0, i.e. "end of list".

According to this old commit I found [1], dummy CUs were used as filler
for incremental LTO linking.  A comment reads:

   WARNING: If THIS_CU is a "dummy CU" (used as filler by the incremental
   linker) then DIE_READER_FUNC will not get called.

In read_cutu_die_from_dwo, however, this check is done after having read
the first DIE.  So at the time of the check, m_info_ptr has already been
advanced just past the first DIE.  As a result, compilations units with
a single DIE are considered (erroneously, IMO) as dummy.

In commit aab6de1613df ("gdb/dwarf: fix spurious error when encountering
dummy CU") [2], I mentioned a real world case where compilation units
with a single top-level DIE were being considered dummy.  I believe that
those units should not actually have been treated as dummy.  A CU with
just one DIE may not be very interesting, but I don't see any reason to
consider it dummy.

Move the dummy check above the read_toplevel_die call, and return early
if the CU is dummy.

I am 99% convinced that it's not even possible to encounter an empty
unit here, and considered turning it into an assert (it did pass the
testsuite).  This function is passed a dwo_unit, and functions that
create a dwo_unit are:

 - create_debug_type_hash_table (creates a dwo_unit for each type unit
   found in a dwo file)
 - create_cus_hash_table (creates a dwo_unit for each comp unit found in
   a dwo file)
 - create_dwo_unit_in_dwp_v1
 - create_dwo_unit_in_dwp_v2
 - create_dwo_unit_in_dwp_v5

In the first two, there are already dummy checks, so we wouldn't even
get to read_cutu_die_from_dwo for such an empty CU.  However, in the
last three, there is no such checks, we just trust the dwp file's index
and create dwo_units out of that.  So I guess it would be possible to
craft a broken dwp file with a CU that has no DIE.  Out of caution, I
didn't switch that to an assert, but I also don't really know what would
be the mode of failure if that were to happen.

Regtested using the various DWARF target boards on Debian 12.

[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/dee91e82ae87f379c90fddff8db7c4b54a116609#dd409f60ba6f9c066432dafbda7093ac5eec76d1_3434_3419
[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/aab6de1613df693059a6a2b505cc8f20d479d109

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

gdb/dwarf: remove cutu_reader::read_cutu_die_from_dwo abbrev table parameter

This parameter is always used to set cutu_reader::m_dwo_abbrev_table.
Remove the parameter, and have read_cutu_die_from_dwo set the field
directly.

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

aarch64: Add missing FEAT_MEC dc encodings and gate sysregs

FEAT_MEC support was introduced in [1]. However, the dc instruction was
missing these encodings:
- DC CIPAE
- DC CIGDPAE

Furthermore, the Arm ARM states that FEAT_MEC is an optional extension,
introduced for v9.2-a.
Therefore, these sysregs:
- MECIDR_EL2
- MECID_P0_EL2
- MECID_A0_EL2
- MECID_P1_EL2
- MECID_A1_EL2
- VMECID_P_EL2
- VMECID_A_EL2
- MECID_RL_A_EL3

which were introduced in that commit now require -march=armv9.2-a at the very
least to be enabled, as well as the dc encodings.

opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae".
* aarch64-sys-regs.def: Add V8_7A as a requirement for the above system
registers.

gas/testsuite/gas/ChangeLog
* aarch64/mec-invalid.s: Add .arch directive.
* aarch64/mec.d: Add .arch directive and check for cipae, cigdpae.
* aarch64/mec.s: Add MEC data cache operations test.
* aarch64/mec-arch-bad.d: New test to check for bad arch version.
* aarch64/mec-arch-bad.l: Above.

[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3

Regression tested on aarch64-none-elf

Introduce gdb_bfd_canonicalize_symtab

bfd_canonicalize_symtab stores the symbols in the BFD, and returns
pointers to these.  The ELF reader does not reuse these stored
symbols, so each call to bfd_canonicalize_symtab causes an allocation.

This interacts poorly with code like arm_pikeos_osabi_sniffer, which
searches the BFD symbol when called.

PR gdb/32758 points out a particularly pathological case: using "maint
info sections" on a program with a large number of sections (10000)
will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G.

I'm not sure BFD always worked this way.  And, fixing BFD was an
option.  However it seemed maybe better for GDB to adapt, since
adapting would mean that the fix would apply to all BFD back ends, and
not just ELF.

To that end, this patch adds a new gdb_bfd_canonicalize_symtab and
changes all callers of bfd_canonicalize_symtab to use it instead.
This new function caches the result in the per-BFD object.

I looked into having this return a view of "const asymbol *".  However
both the compile module and machoread modify the returned symbols.
And while I think this is wrong, I haven't tried to fix this here.

Regression tested on x86-64 Fedora 40.

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

Add compile test for color option

Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)")
fixed a compilation error in color_option_def when building with
clang.  It seemed to me that it would be good to add a compile test
for this code.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: Test the effect of amdgpu-precise memory

The gdb.rocm/precise-memory.exp test currently checks that the "amdgpu
precise-memory" setting can be set.  It does not test that this setting
has any meaningful effect.

This patch extends this test to ensure that precise-memory has the
expected behaviour.

Change-Id: I58f72a51a566f04fc89114b94ee656c2e7ac35bb
Approved-by: Pedro Alves <pedro@palves.net>

gdb/testsuite/lib/rocm: Drop hip_devices_support_precise_memory

Remove hip_devices_support_precise_memory as this is not used anymore.

Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967
Approved-by: Pedro Alves <pedro@palves.net>

gdb/testsuise: gdb.rocm/precise-memory.exp to not require hip_devices_support_precise_memory

The gdb.rocm/precise-memory.exp test adjusts its behaviour based on the
value returned by hip_devices_support_precise_memory.  This function has
static assumption regarding HW capabilities, which might not be
accurate.

Adjust the test so it does not assume anything about HW capabilities,
but instead just ensure that GDB behaves consistently.

Change-Id: Ie1f9c6219b88b94f6d461a254b2ad616b92db6b9
Approved-by: Pedro Alves <pedro@palves.net>

Introduce die_info::children and use it

This adds a new die_info::children method.  This returns a range that
can be used to iterate over a DIE's children.

Then this goes through and updates all the relevant loops to use
foreach instead.  This is a net code reduction.

You'll note that in some places the code was checking the tag as well,
like:

      while (child_die && child_die->tag)

I believe this can't happen and is just a copy-paste oddity from the
old days.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Rename die_info::sibling to die_info::next

I want to add support for C++ foreach iteration over DIE siblings.

I considered writing a custom iterator for this, but it would be
largely identical to the already-existing next_iterator.  I didn't
want to duplicate the code...

Then I tried parameterizing next_iterator by having it take an
optional pointer-to-member template argument.  However, this would
involve changes in many places, because currently a next_iterator can
be instantiated before the underlying type is complete.

So in the end I decided to rename die_info::sibling to die_info::next.
This name is slightly worse but (1) IMO it isn't really all that bad,
nobody would have blinked if it was called 'next' in the initial
patch, and (2) with the change to iteration it is barely used.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simplify warning_pre_print

This changes warning_pre_print to not include the text "warning",
which is now unconditional.  I think this is a bit clearer, and anyway
it is convenient to support the next patch.

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

Do not use warning_pre_print in linux-thread-db.c

linux-thread-db.c may print "warning_pre_print" before displaying an
error message.  This seems like a mistake to me, and furthermore I
think it's best to be as sparing as possible with uses of
warning_pre_print, so this patch removes the prefix.

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

gdb: check styled status of source cache entries

Currently GDB's source cache doesn't track whether the entries within
the cache are styled or not.  This is pretty much fine, the assumption
is that any time we are fetching source code, we do so in order to
print it to the terminal, so where possible we always want styling
applied, and if styling is not applied, then it is because that file
cannot be styled for some reason.

Changes to 'set style enabled' cause the source cache to be flushed,
so future calls to fetch source code will regenerate the cache entries
with styling enabled or not as appropriate.

But this all assumes that styling is either on or off, and that
switching between these two states isn't done very often.

However, the Python API allows for individual commands to be executed
with styling turned off via gdb.execute().  See commit:

  commit e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
  Date:   Thu Feb 13 15:39:31 2025 +0000

      gdb/python: new styling argument to gdb.execute

Currently the source cache doesn't handle this case. Consider this:

  (gdb) list main
  ... snip, styled source code displayed here ...
  (gdb) python gdb.execute("list main", True, False, False)
  ... snip, styled source code is still shown here ...

In the second case, the final `False` passed to gdb.execute() is
asking for unstyled output.

The problem is that, `get_source_lines` calls `ensure` to prime the
cache for the file in question, then `extract_lines` just pulls the
lines of interest from the cached contents.

In `ensure`, if there is a cache entry for the desired filename, then
that is considered good enough.  There is no consideration about
whether the cache entry is styled or not.

This commit aims to fix this, after this commit, the `ensure` function
will make sure that the cache entry used by `get_source_lines` is
styled correctly.

I think there are two approaches I could take:

  1. Allow multiple cache entries for a single file, a styled, and
     non-styled entry.  The `ensure` function would then place the
     correct cache entry into the last position so that
     `get_source_lines` would use the correct entry, or

  2. Have `ensure` recalculate entries if the required styling mode is
     different to the styling mode of the current entry.

Approach #1 is better if we are rapidly switching between styling
modes, while #2 might be better if we want to keep more files in the
cache and we only rarely switch styling modes.

In the end I chose approach #2, but the good thing is that the changes
are all contained within the `ensure` function.  If in the future we
wanted to change to strategy #1, this could be done transparently to
the rest of GDB.

So after this commit, the `ensure` function checks if styling is
currently possible or not.  If it is not, and the current entry is
styled, then the current entry only is dropped from the cache, and a
new, unstyled entry is created.  Likewise, if the current entry is
non-styled, but styling is required, we drop one entry and
recalculate.

With this change in place, I have updated set_style_enabled (in
cli/cli-style.c) so the source cache is no longer flushed when the
style settings are changed, the source cache will automatically handle
changes to the style settings now.

This problem was discovered in PR gdb/32676.

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

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

strip: don't corrupt PE binary's section/file alignment

Section and file alignment are supposed to remain unaltered when PE
binaries are stripped. While this is the case when they're strip-ed
individually, passing multiple such files to strip would reset the
two values to their defaults in all but the first of those binaries.

aarch64: simplify RCPC3 unpredictable logic

The original observation was that STILP is warned about when everything
is fine. Documentation, not just for STILP, says explicitly that
behavior is identical to respective pre-existing insns (for STILP in
particular that's STP). With that it's unclear why distinct logic was
added: Other code can be re-used, simply distinguishing by the number of
operands. This was diagnostics also end up more consistent.

Along with adding some STILP uses to the (positive) testcase, also add a
pair of STLR to similarly demonstrate that the register overlap goes
without warning when there's no write-back.

RISC-V: Ssnpm, smnpm and smmpm imply zicsr.

According to the spec[1], imply zicsr for ssnpm, smnpm and smmpm.

[1] https://github.com/riscv/riscv-j-extension/blob/master/zjpm/instructions.adoc

bfd/ChangeLog:

* elfxx-riscv.c: imply zicsr.

Automatic date update in version.in

[gdbsupport] Fix typo in common-inferior.h

Fix the following typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/
gdbsupport/common-inferior.h:57: elemets ==> elements
...

x86-64: Remove the unused pr19636-3d.d

Remove the unused pr19636-3d.d since static Position Dependent Executable
doesn't have a dynamic symbol table.

PR ld/32807
* testsuite/ld-x86-64/pr19636-3d.d: Removed.

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

[gdb/testsuite] Fix typos in gdb.threads/infcall-from-bp-cond-simple.exp

Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp.

Fix grammar error in dwarf2/attribute.h

A recent patch of mine had a comment with bad grammar; apparently I
didn't finish editing it.  This patch cleans it up.

[gdb/testsuite] Add missing returns in gdb.threads/infcall-from-bp-cond-simple.c

While investigating PR32785 I noticed a missing return statement in
worker_func, and compiling with -Wreturn-type showed another in
function_that_segfaults:
...
$ gcc gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c -Wreturn-type
infcall-from-bp-cond-simple.c: In function ‘function_that_segfaults’:
infcall-from-bp-cond-simple.c:46:1: warning: \
  control reaches end of non-void function [-Wreturn-type]
   46 | }
      | ^
infcall-from-bp-cond-simple.c: In function ‘worker_func’:
infcall-from-bp-cond-simple.c:58:1: warning: \
  control reaches end of non-void function [-Wreturn-type]
   58 | }
      | ^
...

Fix these by adding the missing returns.