testsuite: libsframest: more renames

and fixing some formatting issues.

ChangeLog:
* include/sframe-stacktrace-api.h
* sframe-stacktrace.c
* sframe-state.c
* sframe-state.h

testsuite: libsframest: create new sframest_sfinfo_init

ChangeLog:
* sframe-state.c
* sframe-state.h

testsuite: libsframest: define a new function sframest_sfinfo_addr_range_p

Use this function consistently and remove unnecessary API
sframest_update_sfinfo.

ChangeLog:
* sframe-stacktrace.c
* sframe-state.c
* sframe-state.h

more renames for readability

ChangeLog:
* sframe-stacktrace.c
* sframe-state.c
* sframe-state.h

testsuite: libsframest: rename for readability

Some struct names and member names were long and unintuitive.  Reduce
the technical debt and make the code hopefully easier to maintain.

libsframe/testsuite/
* libsframe.stacktrace/libsframest/sframe-stacktrace.c
* libsframe.stacktrace/libsframest/sframe-state.c
* libsframe.stacktrace/libsframest/sframe-state.h

testsuite: libsframest: use shorter version in conditionals

libsframe/testsuite/

* libsframe.stacktrace/libsframest/sframe-stacktrace.c
* libsframe.stacktrace/libsframest/sframe-state.c

libsframest: use access API instead of direct access using FRE info

libsframe/testsuite/

            * libsframe.stacktrace/libsframest/sframe-backtrace.c

lisbframest: remove unnecessary arch-specific code

ChangeLog:
* libsframe/testsuite/libsframe.stacktrace/libsframest
/sframe-stacktrace.c (sframe_unwind): Remove unnecessary guards
and arch-specific handling.

testsuite: minor housekeeping

Fix some code formatting nits.

libsframe/testsuite/

        * libsframe.stacktrace/libsframest/sframe-stacktrace-err.c:
        * libsframe.stacktrace/libsframest/sframe-stacktrace.c:
        * libsframe.stacktrace/libsframest/sframe-state.c:
        * libsframe.stacktrace/libsframest/sframe-state.h:
        * libsframe.stacktrace/stacktrace-inline-2.c:

testsuite: libsframest: use as, ld, collect-ld from build dir

instead of host's as and ld.  Also disable libsframest build if cross
compiling.  The testsuite will consequently also be skipped.

Override the check-am make target and first execute setup.sh to bring in
the as-new / ld-new and use -B<path> to ensure these are picked up for
building:
  - libsframest
  - libsframe.stacktrace testsuite

Remove the configure time variable HAVE_SFRAME_AS as it is now
unnecessary.

TBD:
  - Get review on whether the whole setup.sh way of doing this is OK.
    But it seems there is no other way ?
  - Check the portability of the setup.sh script.

ChangeLog:
* libsframe/Makefile.am: Override check-am to first run setup.sh
before invoking make.  This ensures libsframest is built with
the newly setup tmpdir/libsframe.
* libsframe/Makefile.in: Regenerate.
* libsframe/acinclude.m4: Delete.
* libsframe/aclocal.m4: Remove include for acinclude.m4.
* libsframe/configure: Regenerate.
* libsframe/configure.ac: Remove HAVE_SFRAME_AS.  Add a new
AM_CONDITIONAL for CROSS_COMPILE.
* libsframe/setup.sh: New file.
* libsframe/testsuite/config/default.exp: Remove the creation
and setup of tmpdir/lisframe.
* libsframe/testsuite/lib/sframe-lib.exp: Use -B<path> to use
the as/ld from build tree.
* libsframe/testsuite/libsframe.stacktrace/libsframest/local.mk:
Use -B<path> and use the as/ld from build tree.
* libsframe/testsuite/libsframe.stacktrace/stacktrace.exp: Skip
testing if cross build.

libsframest: use as a test tool instead

Add a configure time check for dl_iterate_phdr and run
libsframe.stacktrace testsuite using libsframest.  libsframest is the
library for stack tracing using the SFrame stack trace format.

libsframest is not installed anymore but used in the testsuite only.

TBD:
  - More renamings are in order.
  - Cleanup the .exp files.
  - Disable (libsframest based) stack tracer tests in a cross build

testsuite: sframebt: Add backtrace-1 which uses -O2 always

Keep a testcase with an explicit -O2 for testing purposes.

testsuite: sframebt: Use -fno-optimize-sibling-calls

With -O2 and above, the compiler performs a sibling call optimization as
main () and it's callee have compatible stack usage.  As for generating
stack traces though, there is nothing that any stack trace or unwind
format can do here.  Use -fno-optimize-sibling-calls to at least ensure
the testcase checkes for the complete stack trace.

ChangeLog:

* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.lk:
Use -fno-optimize-sibling-calls.
* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.lk:
Likewise.

sframebt: Factor register access code into a header file

ChangeLog:

* libsframe/sframe-backtrace-regs.h: New file.
* libsframe/sframe-backtrace.c: Use the new abstractions.

unwinder: Add SFrame unwinder tests

[Changes in V4]
  - Addressed Mike's review comments.
    - Be careful with the use of # and dnl in configure.ac
    - Add AC_CANONICAL_TARGET as we check for target.
    - Remove the LC_ALL=C bits.
  - Minor code fixups in the testcases
    - Removed unnecessary unistd.h.
    - use ATTRIBUTE_NOCLONE consistently.
    - Other minor cleanups.
[End of changes in V4]

[Changes in V3]
  - Added two new tests with attributes -f(no-)omit-frame-pointer.
  - Minor adjustments due to buildsystem changes in libsframe.
[End of changes in V3]

[Changes in V2]
  - minor changes in filenames in the testsuite.
[End of changes in V2]

Add tests for backtracing using SFrame section.

ChangeLog:

* libsframe/Makefile.in: Regenerated.
* libsframe/configure: Regenerated.
* libsframe/configure.ac: Check for cross compilation.
* libsframe/testsuite/Makefile.in: Regenerated.
* libsframe/testsuite/config/default.exp: Load
  sframe-lib.exp.
* libsframe/testsuite/libsframe.decode/Makefile.in:
  Regenerated.
* libsframe/testsuite/libsframe.encode/Makefile.in:
  Regenerated.
* libsframe/testsuite/lib/sframe-lib.exp: New file.  Add
  procedures for handling unwinder tests.
* libsframe/testsuite/libsframe.unwind/backtrace.c: New test.
* libsframe/testsuite/libsframe.unwind/backtrace.lk: New test.
* libsframe/testsuite/libsframe.unwind/inline-cmds.c: New test.
* libsframe/testsuite/libsframe.unwind/inline-cmds.lk: New test.
* libsframe/testsuite/libsframe.unwind/inline.c: New test.
* libsframe/testsuite/libsframe.unwind/inline.lk: New test.
* libsframe/testsuite/libsframe.unwind/solib-lib1.c: New test.
* libsframe/testsuite/libsframe.unwind/solib-lib2.c: New test.
* libsframe/testsuite/libsframe.unwind/solib-main.c: New test.
* libsframe/testsuite/libsframe.unwind/solib-main.d: New test.
* libsframe/testsuite/libsframe.unwind/solib.exp: New file.
* libsframe/testsuite/libsframe.unwind/solib-lib1.h: New test.
* libsframe/testsuite/libsframe.unwind/solib-lib2.h: New test.
* libsframe/testsuite/libsframe.unwind/tailcall.c: New test.
* libsframe/testsuite/libsframe.unwind/tailcall.lk: New test.
* libsframe/testsuite/libsframe.unwind/ttest.c: New test.
* libsframe/testsuite/libsframe.unwind/ttest.lk: New test.
* libsframe/testsuite/libsframe.unwind/unwind.exp: New file.
* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.c:
  Likewise.
* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.lk:
  Likewise.
* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.c:
  Likewise.
* libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.lk:
  Likewise.

unwinder: generate backtrace using SFrame format

[Changes in V4]
  - Renamed ESFRAME_* enum error code names to SFRAME_ERR_*.
  - Addressed review comments by Mike.
    - Use AC_CACHE_CHECK macro in sframe.m4
    - Delete config/sframe.m4. Add into libsframe/acinclude.m4.
    - Code fixups.
[End of changes in V4]

[Changes in V3]
  - Use the updated APIs from libsframe.
  - Use sframe_decoder_get_fixed_ra_offset on AMD64 instead of magic
    number -8.
[End of changes in V3]

[Changes in V2]
  - Minor formatting fixes.
[End of changes in V2]

A simple unwinder based on SFrame format.

The unwinder is made available via libsframebt library.

Buildsystem changes have been made to build libsframebt only when
--gsframe support is available in the assembler. These buildsystem
changes are necessary because the SFrame based unwinder the SFrame
unwind info for itself to work.

include/ChangeLog:

* sframe-backtrace-api.h: New file.

ChangeLog:

* libsframe/acinclude.m4: New file.
* libsframe/Makefile.am: Build backtrace functionality in its
own library.  Install libsframebt conditionally.
* libsframe/Makefile.in: Regenerate.
* libsframe/aclocal.m4: Regenerate.
* libsframe/configure: Regenerate.
* libsframe/configure.ac: Check if gas supports --gsframe
command line option.
* libsframe/sframe-backtrace-err.c: New file.
* libsframe/sframe-backtrace.c: New file.

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.

[gdb/build] Fix build with gcc 9

Since commit a691853148f ("gdb/python: introduce gdbpy_registry"), when
building gdb with gcc 9, I run into:
...
In file included from gdb/varobj.c:38:0:
gdb/python/python-internal.h:1211:47: error: expected ‘;’ before ‘<’ token
   using StorageKey = typename registry<O>::key<Storage>;
                                               ^
...
due to this code:
...
template <typename Storage>
class gdbpy_registry
{
  ...

  template<typename O>
  using StorageKey = typename registry<O>::key<Storage>;

  template<typename O>
  Storage *get_storage (O *owner, const StorageKey<O> &key) const
  { ... }

  ...
}
...

As an experiment, I tried out eliminating the type alias:
...
  template<typename O>
  Storage *get_storage (O *owner,
                        const typename registry<O>::key<Storage> &key) const
  { ... }
...
and got instead:
...
In file included from gdb/varobj.c:38:0:
gdb/python/python-internal.h:1211:63: error: non-template ‘key’ used as template
  Storage *get_storage (O *owner,
                        const typename registry<O>::key<Storage> &key) const
                                                     ^~~
gdb/python/python-internal.h:1211:63: note: use ‘registry<O>::template key’ \
  to indicate that it is a template
...

Following that suggestion, I tried:
...
  template<typename O>
  Storage *
  get_storage (O *owner,
               const typename registry<O>::template key<Storage> &key) const
  { ... }
...
which fixed the problem.

Likewise, adding the template keyword in the type alias fixes the original
problem, so fix it like that.

Tested on x86_64-linux.

Automatic date update in version.in

gcore: quote PKGVERSION

Same as 3bed686102cb14552d2ed1b83336453d7ce0dd47. I didn't hit an issue
here -- I think because my /bin/sh is dash and gdb-add-index has a /bin/sh
shebang, while gcore uses bash, but it's still worth fixing (we certainly
do NOT want this to be an array).

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

gdb-add-index: quote PKGVERSION

In Gentoo, we configure our gdb with `--with-pkgversion=` with
"Gentoo VERSION XXXX" where XXX depends on patching (not that we patch
gdb really these days) or vanilla.

Since 71f193a5c1cb02dcde6ac160cdab88e9725862bb, this goes wrong, yielding
```
/usr/bin/gdb-add-index: 25: Syntax error: "(" unexpected
```

with lines 25-26 being:
```
PKGVERSION=(Gentoo 9999 vanilla)
VERSION=17.0.50.20250319-git
```

Quote both assignments (PKGVERSION by necessity, VERSION for consistency
or symmetry).

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

gdb/python: convert gdb.Symtab_and_line to use gdbpy_registry

This commit converts gdb.Symtab_and_line to use gdbpy_registry for
lifecycle management.

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

gdb/python: convert gdb.Symtab to use gdbpy_registry

This commit converts gdb.Symtab to use gdbpy_registry for lifecycle
management. Since gdb.Symtab only holds on the struct symtab * (and
prev/next links) the default invalidator can be used.

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

gdb/python: convert gdb.Type to use gdbpy_registry

This commit converts gdb.Type to use gdbpy_registry for lifecycle
management.

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

gdb/python: convert gdb.Symbol to use gdbpy_registry

This commit converts gdb.Symbol to use gdbpy_registry for lifecycle
management. Since gdb.Symbol only holds on the struct symbol * (and
prev/next links) the default invalidator can be used.

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

gdb/python: introduce gdbpy_registry

This commit introduces new template class gdbpy_registry to simplify
Python object lifecycle management. As of now, each of the Python
object implementations contain its own (copy of) lifecycle management
code that is largely very similar. The aim of gdbpy_registry is to
factor out this code into a common (template) class in order to simplify
the code.

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

gdb/python: do not hold on gdb.Type object from gdb.Value

Previous commit changed type_to_type_object() so each time it is
called with particular struct value* it returns the same object.

Therefore there's no longer need to hold on type objects (gdb.Type)
from struct value_object in order to preserve identity of gdb.Type
objects held in value_object::type and value_object::dynamic_type
members. This in turn allowed for some simplification in various
functions.

While at it I changed a couple of NULLs to nullptrs.

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

gdb/python: preserve identity for gdb.Type objects

This commit changes type_to_type_object() so that each it is called
with a particular struct type * it returns the very same gdb.Type
object.

This is done in the same way as for gdb.Symtab objects in earlier commit
("gdb/python: preserve identity for gdb.Symtab objects") except that
types may be either objfile-owned or arch-owned.

Prior this commit, arch-owned objects we not put into any list (like
objfile-owned ones) so they could not be easily looked up. This commit
changes the code so arch-owned list are put into per-architecture list
which is then used (solely) for looking up arch-owned gdb.Type.

Another complication comes from the fact that when objfile is about to
be freed, associated gdb.Type instances are not merely invalidated
(like it is done with gdb.Symtab or gdb.Symbol objects) but instead the
type is copied and the copy is arch-owned. So we need two different
"deleters", one for objfile-owned types that copies the type (as before)
and then insert the object to per-architecture list and another one
for arch-owned types.

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

gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_line

Previous commit changed symtab_to_symtab_object() so each time it is
called with particula struct symtab* it returns the same object.

Therefore there's no longer need to hold on symtab object (gdb.Symtab)
from struct sal_object in order to preserve identity of Symtab object
held in gdb.Symtab_and_line.symtab property. This in turn allowed for
some simplification in various functions.

While at it I changed a couple of NULLs to nullptrs.

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

gdb/python: preserve identity for gdb.Symbol objects

This commit changes symbol_to_symbol_object() so that each it is called
with a particular struct symbol * it returns the very same gdb.Symbol
object.

This is done in the same way as for gdb.Symtab objects in earlier commit
("gdb/python: preserve identity for gdb.Symtab objects") except that
symbols may be either objfile-owned or arch-owned.

Prior this commit, arch-owned objects we not put into any list (like
objfile-owned ones) so they could not be easily looked up. This commit
changes the code so arch-owned list are put into per-architecture list
which is then used (solely) for looking up arch-owned gdb.Symbol.

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

gdb/python: preserve identity for gdb.Symtab objects

This commit changes symtab_to_symtab_object() so that each it is called
with a particular struct symtab * it returns the very same gdb.Symtab
object.

This is done by searching per-objfile linked list of instances and - if
found - return it rather than creating new gdb.Symtab.

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

gdb: change set_internalvar_function to take a unique pointer

This makes the transfer of ownership a bit clearer, even though the
internal_function is still held with a raw pointer inside internalval.

Change-Id: Ie8d13270b64737b92291532acfbfcbc992b482b5
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

gdb: handle INTERNALVAR_FUNCTION in clear_internalvar

While checking the list of leaks reported by ASan, I found that
clear_internalvar doesn't free the internal_function object owned by the
internalvar when the internalvar is of kind INTERNALVAR_FUNCTION, fix
that.

Change-Id: I78f53b83b97bae39370a7b5ba5e1cec70626d66a
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

gdb: clear internalvar on destruction

The data associated to an internalvar is destroyed when changing the
kind of the internalvar, but not when it is destroyed.  Fix that by
calling clear_internalvar in ~internalvar.

A move constructor becomes needed to avoid freeing things multiple times
when internalvars are moved (and if we forget it, clang helpfully gives
us a -Wdeprecated-copy-with-user-provided-dtor warning).

Change-Id: I427718569208fd955ea25e94d341dde356725033
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

gdb: C++-ify internal_function

Change the `name` field to std::string, add constructor.  Remove
function `create_internal_function`, since it becomes a trivial wrapper
around the constructor.

Change-Id: Ifc8b1282c442e1930bcd69d6e140128067e49563
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

gdb/python: new styling argument to gdb.execute

Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.

But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.

At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.

I propose that gdb.execute gain a new argument 'styling'.  When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.

For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that.  My assumption here is that
gdb.execute() might be executed by some extension.  If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.

I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else.  This is only a little bit of
consistency, but I still think it's a good thing.

The default for 'styling' will change depending on where the output is
going.  When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True.  When the output is going to a
string, then the default for 'styling' will be False.  Not only does
this match the existing behaviour, but I think this makes sense.  By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.

This fixes part of the problem described in PR gdb/32676.  That bug
tries to capture styled source listing in a string, which wasn't
previously possible.

There are some additional issues with capturing source code; GDB
caches the source code in the source code cache.  However, GDB doesn't
check if the cached content is styled or not.  As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source.  I'll address this issue in a separate
patch.

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

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

gdb: show full shared library memory range in 'info sharedlibrary'

On GNU/Linux (and other targets that use solib-svr4.c) the 'info
sharedlibrary' command displays the address range for the .text
section of each library.  This is a fallback behaviour implemented in
solib_map_sections (in solib.c), for targets which are not able to
provide any better information.

The manual doesn't really explain what the address range given means,
and the .text fallback certainly isn't described.  The manual for
'info sharedlibrary' just says:

  'info share REGEX'
  'info sharedlibrary REGEX'
       Print the names of the shared libraries which are currently loaded
       that match REGEX.  If REGEX is omitted then print all shared
       libraries that are loaded.

In this commit I propose that we should change GDB so that the full
library address range is listed for GNU/Linux (and other solib-svr4
targets).  Though it is certainly useful to know where the .text for a
library is, not all code is placed into the .text section, and data,
or course, is stored elsewhere, so the choice of .text, though not a
crazy default, is still a pretty arbitrary choice.

We do also have 'maintenance info sections', which can be used to find
the location of a specific section.  This is of course, a maintenance
command, but we could make this into a real user command if we wanted,
so the information lost by this change to 'info sharedlibrary' is
still available if needed.

There is one small problem.  After this commit, GDB is still under
reporting the extents of some libraries, in some cases.

What I observe is that sometimes, for reasons that I don't currently
understand, the run-time linker will over allocate memory for the .bss
like sections, e.g. the ELF says that 1 page is required, but 2 or 4
pages will be allocated instead.  As a result, GDB will under report
the extent of the library, with the end address being lower than
expected.  This isn't always the case though, in many cases the
allocates are as I would expect, and GDB reports the correct values.

However, as we have been under reporting for many years, I think this
update, which gets things a lot closer to reality, is a big step in
the right direction.  We can always improve the results more later
on if/when the logic behind the over allocations become clearer.

For testing I've compared the output of 'info proc mappings' with the
output of 'info sharedlibrary' (using a script), using GDB to debug
itself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64,
and other than the over allocation problem described above, the
results all look good to me.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbserver: fix build on NetBSD

The function remove_thread() was changed to a method in 2500e7d7d (gdbserver:
make remove_thread a method of process_info).

Signed-off-by: Wataru Ashihara <wsh@iij.ad.jp>
Change-Id: I4b2d8a6f84b5329b8d450b268fa9453fe424914e

Automatic date update in version.in

gdb/dwarf: use gdb::unordered_set for cooked_index_storage::m_reader_hash

Replace an htab with gdb::unordered_set.  I think we could also use the
dwarf2_per_cu pointer itself as the identity, basically have the
functional equivalent of:

  gdb::unordered_map<dwarf2_per_cu *, cutu_reader_up>

But I kept the existing behavior of using dwarf2_per_cu::index as the
identity.

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

gdb/dwarf: remove type_unit_group

The type_unit_group is an indirection between a stmt_list_hash (possible
dwo_unit + line table section offset) and a type_unit_group_unshareable
that provides no real value.  In dwarf2_per_objfile, we maintain a
stmt_list_hash -> type_unit_group mapping, and in dwarf2_per_objfile, we
maintain a type_unit_group_unshareable mapping.  The type_unit_group
type is empty and only exists to have an identity and to be a link
between the two mappings.

This patch changes it so that we have a single stmt_list_hash ->
type_unit_group_unshareable mapping.

Regression tested on Debian 12 amd64 with a bunch of DWARF target
boards.

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

gdb/dwarf: use gdb::unordered_map for dwarf2_per_bfd::{quick_file_names_table,type_unit_groups}

Change these two hash tables to use gdb::unordered_map.  I changed these
two at the same time because they both use the same key, a
stmt_list_hash.  Unlike other previous patches that used a
gdb::unordered_set, use an unordered_map here because the key isn't
found in the element itself (well, it was before, because of how htab
works, but it didn't need to be).

You'll notice that the type_unit_group structure is empty.  That
structure isn't really needed.  It is removed in the following patch.

Regression tested on Debian 12 amd64 with a bunch of DWARF target
boards.

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

Remove is_nonnegative and as_nonnegative

This removes attribute::is_nonnegative and attribute::as_nonnegative
in favor of a call to unsigned_constant.

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

Handle DW_END_default

I noticed that gdb doesn't handle DW_END_default.  This patch adds
support for this.

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

Assume DW_AT_alignment is unsigned

This changes get_alignment to assume that DW_AT_alignment refers to an
unsigned value.

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

Assume DW_AT_decl_line is unsigned

This changes read_decl_line and new_symbol to assume that
DW_AT_decl_line should refer to an unsigned value.

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

Use form name in complaint in dwarf2_record_block_entry_pc

This changes dwarf2_record_block_entry_pc to issue a complaint using
the form name rather than a value.  This seems more correct to me.

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

Introduce and use attribute::unsigned_constant

This introduces a new 'unsigned_constant' method on attribute.  This
method can be used to get the value as an unsigned number.  Unsigned
scalar forms are handled, and signed scalar forms are handled as well
provided that the value is non-negative.

Several spots in the reader that expect small DWARF-defined constants
are updated to use this new method.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Rename form_is_signed to form_is_strictly_signed

This renames attribute::form_is_signed to form_is_strictly_signed.  I
think this more accurately captures what it does: it says whether a
form will always use signed data -- not whether a form might use
signed data, which DW_FORM_data* do depending on context.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Fix gdb.base/enum_cond.exp on arm-linux

On arm-linux, I run into:
...
gdb compile failed, ld: warning: enum_cond.o uses variable-size enums yet \
  the output is to use 32-bit enums; use of enum values across objects may fail
UNTESTED: gdb.base/enum_cond.exp: failed to compile
...

Fix this by using -nostdlib.

Tested on arm-linux and x86_64-linux.

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

gdb/dwarf: set m_top_level_die directly in read_cutu_die_from_dwo

read_cutu_die_from_dwo currently returns the dwo's top-level DIE through
a parameter.  Following the previous patch, all code paths end up
setting m_top_level_die.  Simplify this by having read_cutu_die_from_dwo
set m_top_level_die directly.  I think it's easier to understand,
because there's one less indirection to follow.

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

gdb/dwarf: fix spurious error when encountering dummy CU

I built an application with -gsplit-dwarf (i.e. dwo), and some CUs are
considered "dummy" by the DWARF reader.  That is, the top-level DIE
(DW_TAG_compile_unit) does not have any children.  Here's the skeleton:

    0x0000c0cb: Compile Unit: length = 0x0000001d, format = DWARF32, version = 0x0005, unit_type = DW_UT_skeleton, abbr_offset = 0x529b, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000c0ec)

    0x0000c0df: DW_TAG_skeleton_unit
                  DW_AT_stmt_list [DW_FORM_sec_offset]      (0x09dee00f)
                  DW_AT_dwo_name [DW_FORM_strp]     ("CMakeFiles/lib_crl.dir/crl/dispatch/crl_dispatch_queue.cpp.dwo")
                  DW_AT_comp_dir [DW_FORM_strp]     ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")
                  DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)

And here's the entire debug info in the .dwo file:

    .debug_info.dwo contents:
    0x00000000: Compile Unit: length = 0x0000001a, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_compile, abbr_offset = 0x0000, addr_size = 0x08, DWO_id = 0x0ed2693dd2a756dc (next unit at 0x0000001e)

    0x00000014: DW_TAG_compile_unit
                  DW_AT_producer [DW_FORM_strx]     ("GNU C++20 14.2.1 20250207 -mno-direct-extern-access -mtune=generic -march=x86-64 -gsplit-dwarf -g3 -gz=none -O2 -std=gnu++20 -fPIC -fno-strict-aliasing")
                  DW_AT_language [DW_FORM_data1]    (DW_LANG_C_plus_plus_14)
                  DW_AT_name [DW_FORM_strx] ("/home/simark/src/tdesktop/Telegram/lib_crl/crl/dispatch/crl_dispatch_queue.cpp")
                  DW_AT_comp_dir [DW_FORM_strx]     ("/home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/Telegram/lib_crl")

When loading the binary in GDB, I see some warnings:

    $ ./gdb -q -nx --data-directory=data-directory -ex 'maint set dwarf sync on' -ex  "file /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop"
    Reading symbols from /home/simark/src/tdesktop/build-relwithdebuginfo-split-nogz/telegram-desktop...
    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc0cb
    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc152
    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc194
    DWARF Error: unexpected tag 'DW_TAG_skeleton_unit' at offset 0xc1b5
    (gdb)

It turns out that these errors are not really justified.  What happens
is:

 - cutu_reader::read_cutu_die_from_dwo return 0, indicating that the CU
   is "dummy"
 - back in cutu_reader::cutu_reader, we omit setting m_top_level_die to
   the DIE from the dwo file, meaning that m_top_level_die keeps
   pointing to the DIE from the main file (DW_TAG_skeleton_unit)
 - later, in cutu_reader::prepare_one_comp_unit, there is a check that
   m_top_level_die->tag is one of DW_TAG_{compile,partial,type}_unit,
   which triggers

My proposal to fix this is to set m_top_level_die even if the CU is
dummy.  Even if the top-level DIE does not have any children, I don't
see any reason to leave cutu_reader::m_top_level_die in a different
state than when the CU is not dummy.

While at it, set m_dummy_p directly in read_cutu_die_from_dwo, instead
of returning a value and having the caller do it.  This is all inside
cutu_reader anyway.

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

gdb/dwarf: remove create_dwo_cu_reader

This function, as can be seen by its comment, is a remnant of past
design.  Inline its content into create_cus_hash_table.

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

gdb: split up construct_inferior_arguments

The function construct_inferior_arguments (gdbsupport/common-inferior.cc)
currently escapes all special shell characters.  After this commit
there will be two "levels" of quoting:

  1. The current "full" quoting, where all posix shell special
  characters are quoted, and

  2. a new "reduced" quoting, where only the characters that GDB sees
  as special (quotes and whitespace) are quoted.

After this, almost all construct_inferior_arguments calls will use the
"full" quoting, which is the current quoting.  The "reduced" quoting
will be used in this commit to restore the behaviour that was lost in
the previous commit (more details below).

In the future, the reduced quoting will be useful for some additional
inferior argument that I have planned.  I already posted my full
inferior argument work here:

  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

But that series is pretty long, and wasn't getting reviewed, so I'm
posted the series in parts now.

Before the previous commit, GDB behaved like this:

  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
  (gdb) show args
  Argument list to give program being debugged when it is started is "$FOO".

Notice that with 'startup-with-shell' off, the argument was left as
just '$FOO'.  But after the previous commit, this changed to:

  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
  (gdb) show args
  Argument list to give program being debugged when it is started is "\$FOO".

Now the '$' is escaped with a backslash.  This commit restores the
original behaviour, as this is (currently) the only way to unquoted
shell special characters into arguments from the GDB command line.
The series that I listed above includes a new command line option for
GDB which provides a better approach for controlling the quoting of
special shell characters, but that work requires these patches to be
merged first.

I've split out the core of construct_inferior_arguments into the new
function escape_characters, which takes a set of characters to escape.
Then the two functions escape_shell_characters and
escape_gdb_characters call escape_characters with the appropriate
character sets.

Finally, construct_inferior_arguments, now takes a boolean which
indicates if we should perform full shell escaping, or just perform
the reduced escaping.

I've updated all uses of construct_inferior_arguments to pass a
suitable value to indicate what escaping to perform (mostly just
'true', but one case in main.c is different), also I've updated
inferior::set_args to take the same boolean flag, and pass it through
to construct_inferior_arguments.

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

gdb: remove the !startup_with_shell path from construct_inferior_arguments

In the commit:

  commit 0df62bf09ecf242e3a932255d24ee54407b3c593
  Date:   Fri Oct 22 07:19:33 2021 +0000

      gdb: Support some escaping of args with startup-with-shell being off

nat/fork-inferior.c was updated such that when we are starting an
inferior without a shell we now remove escape characters.  The
benefits of this are explained in that commit, but having made this
change we can now make an additional change.

Currently, in construct_inferior_arguments, when startup_with_shell is
false we construct the inferior argument string differently than when
startup_with_shell is true; when true we apply some escaping to
special shell character, when false we don't.

This commit simplifies construct_inferior_arguments by removing the
!startup_with_shell case, and instead we now apply escaping in all
cases.  This is fine because, thanks to the above commit the escaping
will be correctly removed again when we call into nat/fork-inferior.c.

We should think of construct_inferior_arguments and
nat/fork-inferior.c as needing to cooperate in order for argument
handling to work correctly.

construct_inferior_arguments converts a list of separate arguments
into a single string, and nat/fork-inferior.c splits that single
string back into a list of arguments.  It is critical that, if
nat/fork-inferior.c is expecting to remove a "layer" of escapes, then
construct_inferior_arguments must add that expected "layer",
otherwise, we end up stripping more escapes than expected.

The great thing (I think) about the new configuration, is that GDB no
longer cares about startup_with_shell at the point the arguments are
being setup.  We only care about startup_with_shell at the point that
the inferior is started.  This means that a user can set the inferior
arguments, and then change the startup-with-shell setting, and GDB
will do what they expect.

Under the previous system, where construct_inferior_arguments changed
its behaviour based on startup_with_shell, the user had to change the
setting, and then set the arguments, otherwise, GDB might not do what
they expect.

There is one slight issue with this commit though, which will be
addressed by the next commit.

For GDB's native targets construct_inferior_arguments is reached via
two code paths; first when GDB starts and we combine arguments from
the command line, and second when the Python API is used to set the
arguments from a sequence.  It's the command line argument handling
which we are interested in.

Consider this:

  $ gdb --args /tmp/exec '$FOO'
  (gdb) show args
  Argument list to give program being debugged when it is started is "\$FOO".

Notice that the argument has become \$FOO, the '$' is now quoted.

This is because, by quoting the argument in the shell command that
started GDB, GDB was passed a literal $FOO with no quotes.  In order
to ensure that the inferior sees this same value, GDB added the extra
escape character.  When GDB starts with a shell we pass \$FOO, which
results in the inferior seeing a literal $FOO.

But what if the user _actually_ wanted to have the shell GDB uses to
start the inferior expand $FOO?  Well, it appears this can't be done
from the command line, but from the GDB prompt we can just do:

  (gdb) set args $FOO
  (gdb) show args
  Argument list to give program being debugged when it is started is "$FOO".

And now the inferior will see the shell expanded version of $FOO.

It might seem like we cannot achieve the same result from the GDB
command line, however, it is possible with this trick:

  $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO'
  (gdb) show args
  Argument list to give program being debugged when it is started is "$FOO".
  (gdb) show startup-with-shell
  Use of shell to start subprocesses is off.

And now the $FOO is not escaped, but GDB is no longer using a shell to
start the inferior, however, we can extend our command line like this:

  $ gdb -eiex 'set startup-with-shell off' \
        -ex 'set startup-with-shell on' \
--args /tmp/exec '$FOO'
  (gdb) show args
  Argument list to give program being debugged when it is started is "$FOO".
  (gdb) show startup-with-shell
  Use of shell to start subprocesses is on.

Use an early-initialisation option to disable startup-with-shell, this
is done before command line argument processing, then a normal
initialisation option turns startup-with-shell back on after GDB has
processed the command line arguments!

Is this useful?  Yes, absolutely.  Is this a good user experience?
Absolutely not.  And I plan to add a new command line option to
GDB (and gdbserver) that will allow users to achieve the same
result (this trick doesn't work in gdbserver as there's no
early-initialisation there) without having to toggle the
startup-with-shell option.  The new option can be found in the series
here:

  https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com

The problem is that, that series is pretty long, and getting it
reviewed is just not possible.  So instead I'm posting the individual
patches in smaller blocks, to make reviews easier.

So, what's the problem?  Well, by removing the !startup_with_shell
code path from GDB, there is no longer a construct_inferior_arguments
code path that doesn't quote inferior arguments, and so there's no
longer a way, from the command line, to set an unquoted '$FOO' as an
inferior argument.  Obviously, this can still be done from GDB's CLI
prompt.

The trick above is completely untested, so this regression isn't going
to show up in the testsuite.

And the breakage is only temporary.  In the next commit I'll add a fix
which restores the above trick.

Of course, I hope that this fix will itself, only be temporary.  Once
the new command line options that I mentioned above are added, then
the fix I add in the next commit can be removed, and user should start
using the new command line option.

After this commit a whole set of tests that were added as xfail in the
above commit are now passing.

A change similar to this one can be found in this series:

  https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/

which I reviewed before writing this patch.  I don't think there's any
one patch in that series that exactly corresponds with this patch
though, so I've listed the author of the original series as co-author
on this patch.

Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392

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

Preserve a local variable in a gdb test

I found another Ada test where LLVM optimizes away an unused local
variable.  This patch fixes this problem -- but note the test now
fails for a different (currently expected) reason.

Updated translations for BFD and BINUTILS sub-directories

Use gdb unordered map in regcache.c

This changes a couple spots in regcache.c to use gdb::unordered_map.

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

Use gdb unordered map in tui-io.c

This changes tui.c to use gdb::unordered_map.  ui_file_style::color is
changed a little as well; operator< is no longer needed, but a simple
hash function is added.

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

Use gdb unordered set and map in cp-namespace.c

This changes cp-namespace.c to use gdb::unordered_map.

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

Use gdb unordered map in xml-tdesc.c

This changes xml-tdesc.c to use gdb::unordered_map.

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

Use gdb unordered set and map in unit tests

This changes some unit test code to use gdb:unordered_set and
gdb::unordered_map.

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

Use gdb unordered map in target.c

This changes corelow.c to use gdb::unordered_map.

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

Use gdb unordered map in ravenscar.c

This changes ravenscar.c to use gdb::unordered_map.

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

Use gdb unordered set and map in Python layer

This changes a couple of files in the Python layer to use
gdb:unordered_set and gdb::unordered_map.  Another use exists but I
think it is being handled by Jan's series.

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

Use gdb unordered set in linux-procfs.c

This changes linux-procfs.c to use gdb:unordered_set.

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

Use gdb unordered map in linux-nat.c

This changes one spot in linux-nat.c to use gdb::unordered_map.
(There are still other spots that could be converted.)

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

Use gdb unordered map for complaints

This changes the complaints code to use gdb::unordered_map.

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

Use gdb unordered map in stap-probe.c

This changes stap-probe.c to use gdb::unordered_map.

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

Use gdb unordered map in inferior.h

This changes inferior.h to use gdb::unordered_map.

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

Use gdb unordered map in ada-exp.y

This changes ada-exp.y to use gdb::unordered_map.

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

Use gdb unordered set in symtab.c

This changes symtab.c to use gdb:unordered_set.

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

Use gdb unordered map in gdb_bfd.c

This changes gdb_bfd.c to use gdb:unordered_map.

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

Use gdb unordered map in dictionary.c

This changes dictionary.c to use gdb::unordered_map.

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

Use gdb unordered set in breakpoint.c

This changes breakpoint.c to use gdb:unordered_set.

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

Use gdb unordered set and map in corelow.c

This changes corelow.c to use gdb:unordered_set and
gdb::unordered_map.

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

Use scoped_fd in linux-nat.c:proc_mem_file

This changes linux-nat.c:proc_mem_file to use a scoped_fd and fixes up
the users.  Regression tested on x86-64 Fedora 40.

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

[gdb/tdep] Use SYSCALL_MAP_RENAME for aarch64 and loongarch

There are currently two functions using macros SYSCALL_MAP and
UNSUPPORTED_SYSCALL_MAP: aarch64_canonicalize_syscall, and
loongarch_canonicalize_syscall.

Here [1] I propose to do the same in i386_canonicalize_syscall, using one
additional macro: SYSCALL_MAP_RENAME.

Add the same macro in aarch64_canonicalize_syscall and
loongarch_canonicalize_syscall, and use it to map aarch64_sys_mmap and
loongarch_sys_mmap to gdb_sys_mmap2.

While we're at it:
- reformat the macro definitions to be more readable,
- add missing macro undefs in aarch64_canonicalize_syscall, and
- fix indentation in aarch64_canonicalize_syscall.

No functional changes.

Tested by rebuilding on x86_64-linux.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216230.html

RISC-V: Support pointer masking extension 1.0

- Adding Ssnpm, Smnpm, Smmpm, Sspm, and Supm
- No new CSR added
- Pointer masking only applies to RV64
- Ref: https://github.com/riscv/riscv-j-extension/releases/download/pointer-masking-ratified/pointer-masking-ratified.pdf

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

gas/NEW: Updated news related to mapping symbol and extensions for risc-v

RISC-V: Add extension XTheadVdot for T-Head VECTOR vendor extension [1]

T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.

This patch adds the additional extension "XTheadVdot" based on the
"V" extension, and it provides four 8-bit multiply and add with
32-bit instructions for the "v" extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([2]).

Co-Authored-By: Lifang Xia <lifang_xia@linux.alibaba.com>
[1] https://github.com/XUANTIE-RV/thead-extension-spec/tree/master/xtheadvdot
[2] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add support
for "XTheadVdot" extension.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* doc/c-riscv.texi: Likewise.
* testsuite/gas/riscv/march-help.l: Likewise.
* testsuite/gas/riscv/x-thead-vdot.d: New test.
* testsuite/gas/riscv/x-thead-vdot.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_TH_VMAQA_VV): New.
* opcode/riscv.h (enum riscv_insn_class): Add insn class for
XTheadVdot.

opcodes/ChangeLog:

* riscv-opc.c: Likewise.

RISC-V: Avoid parsing arch string repeatedly for dis-assembler

Since we now always generate $x+isa for now, these would increase the
dis-assemble time by parsing the same architecture string repeatedly.  We
already have `arch_str' field into `subset_list' to record the current
architecture stirng, but it's only useful for assembler, since dis-assembler
and linker don't need it before.  Now for dis-assembler, we just need to
update the `arch_str' after parsing the architecture stirng, and then avoid
parsing repeatedly if the strings are the same.