aarch64: Allow multiple fields in {ins|ext}_regno

Adjust SME_PNd3/SME_PNg3 to use explicit FLD_CONST_1 bits.  This allows
the use of operand specific data to be eliminated here.

aarch64: Extend aarch64_field to support constants

Many instructions have constraints on the range of registers they can
use.  This means that some bits in the register number are fixed, and
therefore aren't mapped to a field in the instruction encoding.
Currently we use various adhoc rules to handle these fixed bits, but
this doesn't handle all cases and we often have to write new code to
support new combinations of permitted registers.

This patch allows these constant bits to instead be specified in the
same structure used to represent instruction fields.  Uses of the new
constant fields will be introduced in subsequent patches.

Automatic date update in version.in

Remove linespec.c:symtab_collector class

linespec.c has a symtab_collector class that is readily replaced by a
lambda.  I think the result is more clear.

I considered using the unordered_dense 'extract' method as well, to
make the code a bit more efficient -- but it wasn't clear to me if the
ordering of the vector mattered, and so I've just added a comment.

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

Clean up iterate_over_symtabs

After the "search via psyms" series, there's no need for
iterate_over_symtabs to first check the expanded symtabs -- the
callback will now be called for every relevant symtab, including ones
that were already expanded before the search.

Cleaning this up enables some other cleanups.  In particular,
iterate_over_some_symtabs is not needed in its current form, so here
I've renamed it, made it static, and made it search just a single
compunit symtab.

While there I cleaned up the "invert" logic in
objfile::map_symtabs_matching_filename.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30738
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

Remove an extraneous 'return' from void method

cooked_index_functions::map_symbol_filenames returns 'void' but also
does "return ... expression".  While valid, this seems strange.  This
patch removes the unnecessary 'return'.

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

Convert map_symbol_filenames to method

This patch changes the free function map_symbol_filenames to be a
method of program_space.  This seems a bit cleaner, and also lets us
hoist a use of the global into the callers.

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

doc/gdb.texinfo: Add EIO and ENOSYS errno values

This patch adds the EIO and ENOSYS errno values supported by GDB's
File-I/O to section E.14.9: Errno Values of the GDB manual [1] that were
presumably inadvertently omitted; both can be seen in the enum
fileio_error:gdbsupport/fileio.h and corresponding function
host_to_fileio_error:gdbsupport/fileio.cc as FILEIO_{EIO,ENOSYS}.

FILEIO_SUCCESS remains excluded from the manual, because its stated
purpose (commit b872057a6) is to internally represent the absence of an
error value from the remote, and it's not actually an error number.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Errno-Values.html

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

gas/macro.c getstring

This code:
      if (in->ptr[idx] == '!')
{
  idx++;
  sb_add_char (acc, in->ptr[idx++]);
}
and similar code in the other loop, blindly accessed the next element
of the string buffer without first checking idx against in->len,
leading to uninitialised accesses or buffer overruns.  Fix that, and
tidy the loops so that the function always returns the index one past
the last char consumed.  (It could return idx == in->len + 1).

* macro.c (getstring): Don't access past end of input string
buffer.  Tidy loops.  Don't return an index past in->len.

gdb/testsuite: make gdb.tui/gdb.sh work with dash

gdb.tui/gdb.sh (used by test gdb.tui/tuiterm-2.exp) doesn't run well
when /bin/sh is dash:

    $ bash testsuite/gdb.tui/gdb.sh
    foo^C
    $ dash testsuite/gdb.tui/gdb.sh
    footestsuite/gdb.tui/gdb.sh: 20: read: arg count

shellcheck actually points it out:

    In testsuite/gdb.tui/gdb.sh line 20:
    read
    ^--^ SC3061 (warning): In POSIX sh, read without a variable is undefined.
    ^--^ SC2162 (info): read without -r will mangle backslashes.

Fix the issue by passing the `_` dummy variable.  Using that particular
variable will not cause shellcheck to whine about it being unused.  Also
add `-r` to make it happy.

Change-Id: Ida3eddbfa3473487743fc96615baf735b4773738

Automatic date update in version.in

hppa64: Fix relocation handling for global data and a couple of thinkos

This fixes relocation handling in situations where hh->owner and
hh->sym_indx were not initialized.

2025-10-08  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

PR binutils/6511
* elf64-hppa.c (global_sym_index): New from ia64.
(elf64_hppa_check_relocs): Only set hh->eh.ref_regular if we
have a regular definition.
(elf64_hppa_check_relocs): Add missing NEED_DYNREL to need_entry
assignment.
(elf64_hppa_check_relocs): Stash symbol index and section
earlier.
(allocate_global_data_dlt): Initialize hh->owner and hh->sym_indx
if not initialized.
(allocate_global_data_opd): Likewise.  Remove redundant checks
for NULL hh.
(allocate_dynrel_entries): Check for discarded
hppa_info->other_rel_sec section.  Add assert rent->sec->owner
== hh->owner.
(elf64_hppa_finalize_dynreloc): Check for discarded
hppa_info->other_rel_sec section.
(elf_hppa_final_link_relocate): Return bfd_reloc_ok if we
have R_PARISC_NONE relocation.

[gdb/testsuite] Fix bp loc in gdb.server/fetch-exec-and-args.exp

With test-case gdb.server/fetch-exec-and-args.exp, on aarch64-linux I run into:
...
(gdb) break 28^M
Breakpoint 1 at 0xfffff7fd7b8c: file ../sysdeps/aarch64/dl-start.S, line 30.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 1, _start () at ../sysdeps/aarch64/dl-start.S:30^M
30              mov     x0, sp^M
(gdb) PASS: $exp: packet=on: test_exec_and_arg_fetch: \
  continue to breakpoint: run to breakpoint
print argc^M
No symbol "argc" in current context.^M
(gdb) FAIL: $exp: packet=on: test_exec_and_arg_fetch: print argc
...

The problem is that the "break 28" is not specific about the file.

Fix this by setting the breakpoint on fetch-exec-and-args.c:28.

Tested on aarch64-linux.

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

[gdb/testsuite] Fix ERROR in expect_build_id_in_core_file

With test-case gdb.python/py-corefile.exp I run into:
...
PASS: $exp: test mapped files data: show-build-ids
ERROR: tcl error sourcing gdb.python/py-corefile.exp.
ERROR: bad option "0x1fa178": \
  must be -nobackslashes, -nocommands, or -novariables
    while executing
"subst 0x$offset + 0"
...

Fix this using "[subst 0x$offset]" instead.

Tested on x86_64-linux.

gdb: add tests for per-inferior settings

I am currently upstreaming some patches from ROCgdb that were made a few
years ago. This series cleans up how the CLI and MI access parameters
for multiple inferiors.

A preceding patch (702991711a91 ("gdb: Have setter and getter callbacks
for settings")) allowed for per-inferior getter/setter functions of some
inferior-specific settings. Over the years a few changes were accepted
upstream (cc09d372f664 ("gdb: make set/show args work with
$_gdb_setting_str")) that implemented those capabilities.

This patch adds a few tests to verify that those settings are properly
set and accessed from the CLI, MI as well as the python interface.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I7a5eab210c84d6a6782a32125f68bde34d9a2339
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: make deprecated_show_value_hack use its ui_file parameter

If a setting does not provide a "show" function, we fall back to the
deprecated_show_value_hack function to print the value in a generic
way. The current version ignores the `file` parameter specifying the
output file in favor of always using gdb_stdout.

To make things consistent with how the values are printed using a
regular show command, the proposed change makes the function use the
ui_file parameter it receives (even though do_show_command passes
gdb_stdout).

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I54028ed654a1fa4d955e6e46f979472c8d98ace9
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: do not recompute values for inferior parameters when showing them

When calling the `show` command on a few inferior-specific settings
(inferior-tty, args, cwd), GDB will recompute the values despite them
being provided by a getter.

For instance, When `show cwd` is called, `do_show_command` will query
the value of the `cwd` through `get_inferior_cwd`, which already gets
the per-inferior value. The current version seems to be a workaround
from when settings could not provide a getter function and per-inferior
settings could thus not be implemented properly, forcing the `show`
implementation to recompute the value itself.

The changes clean up the code and makes the show command trust the
values it is being forwarded, as they will always be computed by the
getter function.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I3b25f61f9101d98a6df7d50cee50131aec7e25c9
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: use getter/setter command styles for "set tdesc filename"

The target description filename command pair ("(set|get) tdesc
filename") uses a rather indirect way to set the variable for the
inferior, using a scratch variable to pass the value. While most other
inferior-specific parameters were updated to the more direct
getter/setter style functions, I believe this parameter was an
oversight.

This patch removes the intermediate string and directly accesses the
tdesc filename for the current inferior.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I2a87c65c9931ec91d15f854b32ac8279fe7077be
Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/testsuite] fix gdb.server/server-kill.exp

A test case in gdb.server/server-kill.exp attempts to query the server
status after the server it is connected to has been killed. The
connection is reset as expected, but the regex on the error message
seems to be out-of-date. The test expects:

Remote communication error.  Target disconnected: Connection reset by peer.

But a modern build of gdb yields :

Remote communication error.  Target disconnected: error while reading: Connection reset by peer.

I presume this is due to change 0da23004a064 ("Change serial_readchar to
throw") which added exceptions to the control flow handling instead of
relying on perror(). The exception error string inserts "error while
reading" to the perror message.

The test appeared to fail intermittently, sometimes matching the first
part of the regex ("Remote connection closed"). It now passes
consistently.

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

[gdb/testsuite] fix gdb.multi/checkpoint-multi.exp without symbols

The checkpoint-multi.exp test stops a program while it is sleeping
using a call to the usleep() function from libc. The test checks whether
the inferior is running by matching for "<running>" (if the inferior
is running) or a hex address followed by a function name, ideally, if
the inferior is stopped.

On most systems this works fine :

(gdb) info checkpoints
   Id Active Target Id       Frame
* 1.0 y      process 1546841 at 0x00007ffff7ceca7a, <clock_nanosleep>
  1.1 n      process 1547177 at 0x00005555555551f0, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/hello.c, line 51
  2.0 y      process 1547076 at 0x0000555555555243, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 46
  2.1 n      process 1547120 at 0x0000555555555285, file /home/sdarche/binutils-gdb/build-x86/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 61

I have found however that the output from `info checkpoints` is
different on some systems with (stripped) versions of the libc without
debug infos :

(gdb) info checkpoints
   Id Active Target Id      Frame
* 1.0 y      process 979642 at 0x00007ffff7e49687
  1.1 n      process 979647 at 0x00005555555551ac, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/hello.c, line 51
  2.0 y      process 979645 at 0x000055555555523b, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 46
  2.1 n      process 979646 at 0x0000555555555271, file /home/sdarche/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.multi/goodbye.c, line 61

Where the frame can be found, but GDB cannot find the function. This
fails the last two tests in checkpoint-multi.exp on those system, even
though the behaviour is as expected.

This patch removes the comma from the regex that matches with the frame
number. The test now passes fine on the system.

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

gdb: add Sébastien Darche to gdb/MAINTAINERS

gdb/python: cast to ui_file_style::intensity after validating value

When GDB is built with undefined behavior sanitizer,
gdb.python/py-style.exp fails because of this:

    $ ./gdb -q -nx --data-directory=data-directory -ex "python filename_style = gdb.Style('filename')" -ex "python filename_style.intensity = -3"
    /home/simark/src/binutils-gdb/gdb/python/py-style.c:239:11: runtime error: load of value 4294967293, which is not a valid value for type 'intensity'

Fix it by casting the value to ui_file_style::intensity only after
validating the raw value.

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

gdb/testsuite: fix failure from gdb.python/py-corefile.exp

After commit:

  commit f69c1d03c4d6c68ae3f90facd63245426c028047
  Date:   Mon Aug 25 16:48:22 2025 +0100

      gdb/python: add Corefile.mapped_files method

Tom reported a failure:

  (gdb) check-build-ids
  Python Exception <class 'AssertionError'>: build-id mismatch for /lib64/libc.so.6
  Error occurred in Python: build-id mismatch for /lib64/libc.so.6
  (gdb) FAIL: gdb.python/py-corefile.exp: test mapped files data: check-build-ids

The discussion thread can be found here:

  https://inbox.sourceware.org/gdb-patches/de21b43c-e3bd-4354-aace-bd3f50c1c64c@suse.de

There are a couple of problems.

First, there is an issue where some versions of the linker didn't
place the build-id within the first page of an ELF.  As a result, the
Linux kernel would not include the build-id in the generated core
file, and so GDB cannot to find the build-id.

In this patch I've added mitigation for this problem.

I changed the 'check-build-ids' command (added via Python as part of
the test) to 'show-build-ids'.  The updated command prints a table
containing the build-ids for each objfile as found via GDB's
Progspace.objfiles, and via the Corefile.mapped_files.  This table is
then read by the TCL test script, and the build-ids are checked.  If
there's a difference, then GDB can analyse the on disk ELF and work
out if the difference is due to the linker issue mentioned above.  If
it is, then the difference is ignored.

In order to check for this linker issue I added a new helper proc to
lib/gdb.exp, expect_build_id_in_core_file.

The second problem with the original test is that it would consider
separate debug files as files that should appear in the core file.
There was Python code in the test that filtered the objfile list to
disregard entries that would not appear in the core file, but this
code needed extending to cover separate debug files.

The final issue is that I'm only aware of GNU/Linux forcing the first
page of every mapped ELF into the generated core files, so this test
would likely fail on non-Linux systems.  I've made the part of the
test that relies on this behaviour Linux only.

This change should resolve the FAIL that Tom reported.  Giving Tom a
Co-Author credit as he fixed the second issue, and helped a lot
debugging the first issue.

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

Bump 'isort' version for pre-commit

"pre-commit autoupdate" showed that there is a new version of isort
available.  This patch updates the config.  No other changes were
needed.

gdb: remove program_space::core_bfd member function

This commit removes the program_space::core_bfd member function, which
was left in place as a temporary hack in the last commit in order to
reduce the size of the last commit.

In every place that 'current_program_space->core_bfd ()' was used I
now call 'get_inferior_core_bfd (current_inferior ())'.

I think there is further scope for improving things in the future,
reducing the number of times we access the core file via global state,
but doing that cleanup might be more involved than the clean up I've
done up to this point.  So I'm leaving that work for the future.

But I think in some places, at the top level (e.g. user command
functions), there's always going to be some cases where we just need
to access the current global state, this is just the nature of the
command handlers.

There should be no user visible changes after this commit.

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

gdb: move core file bfd from program_space into core_target

This commit moves the 'gdb_bfd_ref_ptr cbfd' out of program_space and
into core_target, where it is now called m_core_bfd.

I believe this change makes sense as the core_target instance holds
additional information that is parsed from the core file BFD, and so
storing the parsed information separately from the BFD doesn't make
much sense to me.

To minimise the churn in this commit, I have retained the
program_space::core_bfd member function as a temporary hack.  This
function forwards the request to the new function
get_inferior_core_bfd.  This works fine for now as
program_space::core_bfd is, after this commit, only called on the
current_program_space.  If this all seems like a total hack, then it
is, but don't worry too much, the next commit will clean this all up.

I was tempted to make the new function get_inferior_core_bfd, a member
function of the inferior class, inferior::core_bfd.  In fact, that
would have been my preferred change.  However, the new function needs
visibility of the core_target class, which, right now is private
within the corelow.c file.

This shouldn't be a problem, we could just declare the member function
in inferior.h, and implement the function in corelow.c.  But this
would mean the implementation of inferior::core_bfd, would not live in
inferior.c.  Previously when I've implemented member functions outside
their natural home (e.g. an inferior function not in inferior.c) I've
received review feedback that this is not desirable.  So, for now,
I've gone with a free function.

I also needed to change get_current_core_target, renaming it to
get_core_target, and taking an inferior as an argument.  Existing call
sites are updated to pass 'current_inferior ()', but
get_inferior_core_bfd passes something that might not be the current
inferior.

There should be no user visible changes after this commit.

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

aarch64, gas: Relax Armv9.6-A mandatory feature set

Remove FPRCVT and SVE2p2 from the set of mandatory features for Armv9.6-A.

gdb: fix for 'set suppress-cli-notifications on' missed case

I noticed this behaviour:

  (gdb) info threads
    Id   Target Id                               Frame
    1    Thread 0xf7dbc700 (LWP 3161872) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
  * 2    Thread 0xf7dbbb40 (LWP 3161884) "thr" breakpt () at thr.c:19
  (gdb) set suppress-cli-notifications on
  (gdb) thread 1
  (gdb) thread 1
  [Switching to thread 1 (Thread 0xf7dbc700 (LWP 3161872))]
  #0  0xf7eb2888 in clone () from /lib/libc.so.6
  (gdb)

I think that the second 'thread 1' should not produce any output just
like the 'inferior' command, continuing in the same GDB session:

  (gdb) inferior 1
  (gdb)

Without suppress-cli-notifications we would see an inferior, thread,
and frame being printed, but with suppress-cli-notifications set to
on, we get no output.

The difference in behaviours is that in inferior_command (inferior.c),
we always call notify_user_selected_context_changed, even in the case
where the inferior doesn't actually change.

In thread_command (thread.c), we have some code that catches the
thread not changed case, and calls print_selected_thread_frame.  The
notify_user_selected_context_changed function is only called if the
thread actually changes.

I did consider simply extending thread_command to check the global
cli_suppress_notification.user_selected_context state and skipping the
call to print_selected_thread_frame if suppression is on.

However, I realised that calling print_selected_thread_frame actually
introduces a bug.

When the 'thread' command is used to select the currently selected
thread, GDB still calls 'thread_selected'.  And 'thread_select' always
selects frame #0 within that thread, consider this session:

  (gdb) info threads
    Id   Target Id                              Frame
    1    Thread 0xf7dbc700 (LWP 723986) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
  * 2    Thread 0xf7dbbb40 (LWP 723990) "thr" breakpt () at thr.c:19
  (gdb) bt
  #0  breakpt () at thr.c:19
  #1  0x080491fd in thread_worker (arg=0xffff9514) at thr.c:31
  #2  0xf7f7667e in start_thread () from /lib/libpthread.so.0
  #3  0xf7eb289a in clone () from /lib/libc.so.6
  (gdb) frame 3
  #3  0xf7eb289a in clone () from /lib/libc.so.6
  (gdb) thread 2
  [Switching to thread 2 (Thread 0xf7dbbb40 (LWP 723990))]
  #0  breakpt () at thr.c:19
  19   while (stop)
  (gdb) frame
  #0  breakpt () at thr.c:19
  19   while (stop)
  (gdb)

Notice that the frame resets back to frame #0.

By only calling print_selected_thread_frame, and not calling
notify_user_selected_context_changed, this means that GDB will fail to
emit an MI async notification.  It is this async notification which
tells MI consumers that the frame has been reset to #0.

And so, I think that the correct solution is, like with the 'inferior'
command, to always call notify_user_selected_context_changed.

This does mean that in some cases unnecessary MI notifications can be
emitted, however, an MI consumer should be able to handle these.  We
could try to avoid these, but we would need to extend thread_command
to check that neither the thread OR frame has changed after the call
to thread_select, and right now, I'm not sure it's worth adding the
extra complexity.

I've rewritten the gdb.base/cli-suppress-notification.exp test to
cover more cases, especially the reselecting the same thread case.
And I've updated the gdb.mi/user-selected-context-sync.exp test to
allow for the additional MI notifications that are emitted, and to
check the frame reset case.

While working on this change, I did wonder about calls to
notify_user_selected_context_changed for frame related commands.  In
places we do elide calls to notify_user_selected_context_changed if
the frame hasn't changed.  I wondered if there were more bugs here?

I don't think there are though.  While changing the inferior will also
change the selected thread, and the selected frame.  And changing the
thread will also change the selected frame.  Changing the frame is the
"inner most" context related thing that can be changed.  There are no
side effect changes that also need to be notified, so for these cases,
I think we are fine.

Also in infrun.c I fixed a code style issue relating to
notify_user_selected_context_changed.  It's not a functional change
required by this commit, but it's related to this patch, so I'm
including it here.

Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Approved-By: Tom Tromey <tom@tromey.com>

cris: bfd: Default selected target to the configured target

Whether targ_defvec is set to the best match for the configured target
or some of the other supported targets usually doesn't matter, as the
actual target being used, usually is set by some other mechanism, like
an input object file.

In some situations it matters though: it might be confusing to see
--help output not showing the configured target first in the list of
supported targets.  Also, some corner cases risk running into bugs like
PR33485, for cris-elf and cris-linux because cris_aout_vec is the
default target where instead the bug-free behavior of
cris_elf32_us_vec or cris_elf32_vec would be expected.

The test just verifies that the target list emitted for the --help
option has the expected target first.

bfd:

* config.bfd <cris-*-* | crisv32-*-*>: Split into <cris-*-*aout*>,
<cris-*-linux-* | crisv32-*-linux-*>, <cris-*-* | crisv32-*-*> cases
respectively setting targ_defvec per the target instead of always
cris_aout_vec.

binutils:

* testsuite/binutils-all/cris: New directory intended for
tests focused on behavior of the binutils programs, not the assembler
or linker.
* testsuite/binutils-all/cris/cris.exp: New file with run_dump_test
loop.
testsuite/binutils-all/cris/tgt-a.d,
testsuite/binutils-all/cris/tgt-e.d,
testsuite/binutils-all/cris/tgt-l.d: New tests.

Co-authored-by: Maciej W. Rozycki <macro@redhat.com>

Automatic date update in version.in

gdbsupport: make reference_to_pointer_iterator's constructor non-variadic

For the same reason as the previous patches (making things easier to
understand, at the cost of being more explicit), change
reference_to_pointer_iterator's constructor to take an already built
underlying iterator.

There are no uses of this utility in the code base right now, so no
callers to update.

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

gdbsupport: remove variadicity from filtered_iterator constructor

For the same reason as the previous patches (making things easier to
understand, at the cost of being more explicit), remove
filtered_iterator's variadic constructor, forcing the callers to pass
already built underlying iterators.

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

gdbsupport: remove variadicity from basic_safe_iterator constructors

Change the constructors to accept `Iterator` objects directly.  This
requires the callers to explicitly pass `Iterator` object (unless
perhaps `Iterator` has a non-explicit one-argument constructor.

The rationale is the same as the previous patch: make the code easier to
follow and make it easier to fix build errors, at the expense of making
callers more explicit.

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

gdbsupport: remove variadicity from iterator_range constructor

There are two ways to build an iterator_range:

 - Using the variadic constructor, where the arguments you pass are used
   to construct the "begin" underlying iterator.  The "end" iterator is
   obtained by default-constructing the underlying iterator.

 - Using the other constructor, by explicitly providing the "begin" and
   "end" iterators.

My experience is that using the variadic constructor is very confusing,
especially when you have multiple layers of iterator wrappers.  It's not
obvious where the arguments you provide end up.  When you have a
compilation error, it is hard to decipher.

I propose to remove the variadicity of the first constructor of
iterator_range, and subsequently of the other iterator wrappers.  This
requires callers to be more verbose, explicitly instantiate all the
layers.  But since we only instantiate these iterator wrappers in
factory functions, I think it's fine.  If there is a compilation error,
it will be much easier to find and fix the problem.

Using the new one-argument constructor, it is still assumed that the end
iterator can be obtained by default-constructing the underlying iterator
type, which I think is fine and not too confusing.

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

gdb: change objfiles_iterator to yield references

Same rationale as the previous patches.

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

gdb: make lwp_info_iterator yield references

Same rational as the previous patches.

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

gdb: change thread_step_over_list_iterator to yield references

Same rationale as the previous patches.

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

gdb: change all_threads_safe to yield references

To be consistent with all_threads and the others, following the previous
patch.

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

gdb: change inf_threads_iterator to yield references

When adding reference_to_pointer_iterator, I saw it as a temporary
thing, to not have to do a codebase-wide change right away.  Remove it
from inf_threads_iterator and adjust all the users.

It's very possible that I forgot to update some spots in the files I
can't compile, but it will be very easy to fix if that happens.

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

Remove 'sys' import from frame_filters.py

pre-commit (really flake8) points out that a recent change to
frame_filters.py left an unused import.  This patch fixes the problem.

gdb/python: make use of gdb.Style for shipped Python commands

With the recent addition of the gdb.Style Python API, this commit goes
through the gdb.Command sub-classes which we ship with GDB and adds
some styling support.

This adds 'title' style in a couple of places where we layout tables.
And uses 'filename' style where we are printing filenames.

While I was making these changes I've made a couple of related fixes.

In 'info frame-filter', 'info missing-objfile-handlers', 'info
pretty-printer', and 'info xmethod', we would sometimes print the
gdb.Progspace.filename unconditionally, even though this field can
sometimes be None.  To better handle this case, I now check for None,
and print '<no-file>' instead.  We already printed that same string
for the program space name in at least one other case, so this change
makes things a little more consistent.

I don't format the '<no-file>' string with the filename style, only if
we have an actual filename does the string get formatted.

The other fix I made was in 'maint info python-disassemblers'.  Here
I've added an extra space between the two columns in the output
table.  The two columns are 'Architecture' and 'Disassembler Name'.
Given that one column contains a white space, it was rather confusing
having a single space between columns.  Luckily the tests don't depend
on a single space, so nothing needs updating for this change.

Additionally, in 'info frame-filter' I've updated the exception
handling to use the gdb.warning function, rather than just printing a
line of output.  This means that should this case occur we get the
neat little emoji.  We have no tests that trigger this warning, and I
couldn't figure out how to write one.  In this end, I just hacked the
Python code to raise an exception and checked the output looked
reasonable.  I suspect this warning might be a hard one to trigger!

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

Ignore artificial fields in Ada

A user found an unusual Ada situation that DWARF does not readily
support.  Consider this type:

   type Discrete_Typ is tagged null record;
   type Int_Typ (Is_Static : Boolean) is new Discrete_Typ with null record;

   type Signed_Int_Typ (Is_Static : Boolean) is
      new Int_Typ (Is_Static => Is_Static)
                    with record
      case Is_Static is
         when True =>
            Field : Integer;
         when others =>
            null;
      end case;
   end record;

Here, Signed_Int_Typ has a variant part where the discriminant is
stored in a superclass.

Anyway, this code caused gnat-llvm to crash.  While fixing the crash,
I decided to fix this by emitting an anonymous field in Signed_Int_Typ
that represents the discriminant.  This would allow member DIEs to
refer to it -- which I suppose is possibly why DWARF specified that
the discriminant should be a member of the variant (though I don't
really know; this decision always seemed very strange to me).

Making the field anonymous lead to the strange error:

    Type ... is not a structure or union type.

... which comes from lookup_struct_elt, which fails when an anonymous
member of a structure has a non-composite type.  This patch includes a
fix for this issue.

After fixing that, though I decided it would be better if the
artificial discriminant were still given a name.  So, this patch
includes a change to ada_is_ignored_field to ignore artificial fields.

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

Remove some helper functions from DAP breakpoint code

The DAP breakpoint code has some helper functions that don't really
provide much value any more.  This patch removes them.

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

Fix compile-ops.exp

The recent change to change the parsing of location expressions in the
test suite broke compile-ops.exp.  I neglected to update that patch.
This patch fixes the oversight.

tidy coff-alpha.c

Remove K&R required casts.  Formatting fixes.  Localise vars in
alpha_ecoff_get_elt_at_filepos and tidy decompression loop.

[gdb/symtab] Improve invalid range check in create_addrmap_from_gdb_index

When running test-case gdb.tui/tui-missing-src.exp with target board
gold-gdb-index (and likewise fission and fission-dwp) on aarch64-linux, I run
into:
...
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
...

Looking at the gold-gdb-index case, the problem is caused by the address table
of the .gdb_index section:
...
Address table:
000000000040066c 0000000000400694 0
000000000040053f 0000000000400563 1
...

The address range for f2 is [0x400694, 0x4006b8), but the address table says
it's [0x40053f, 0x400563).

The address 0x40053f is not even in a section:
...
  [Nr] Name    Type            Address          Off    Size   ES Flg Lk Inf Al
  ...
  [12] .plt    PROGBITS        00000000004004b8 0004b8 000050 10  AX  0   0  8
  [13] .text   PROGBITS        0000000000400540 000540 000178 00  AX  0   0 64
...
but part of the hole [0x400508, 0x400540) in between .plt and .text.

Detect this in the invalid range check in create_addrmap_from_gdb_index.

Tested on aarch64-linux.

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

Automatic date update in version.in

MIPS/BFD: Fix rightshift for remaining n32 reloc howtos

Correct the rightshift amount for the R_MIPS_HIGHER, R_MIPS_HIGHEST and
R_MIPS_CALL_HI16 RELA relocation howtos, missed with commit f38e9921479a
("MIPS HI16 and LO16 reloc howtos").

MIPS/BFD: Account for VxWorks .got.plt references

On VxWorks calls can refer directly to a .got.plt entry, in which case
they won't have an entry in the regular GOT.  It was missed with commit
6c42ddb92b90 ("MIPS GOT: Remove TLS GOT info from the symbol table"),
<https://inbox.sourceware.org/binutils/878v6uyaw3.fsf@talisman.default/>,
which revamped GOT entry bookkeeping, and consequently space for regular
GOT entries is needlessly reserved and then not used, with extraneous
null dynamic relocations attached, e.g.:

Relocation section '.rela.dyn' at offset 0x1400 contains 11 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00080c0c  00000405 R_MIPS_HI16       00000000   __GOTT_BASE__ + 0
00080c10  00000406 R_MIPS_LO16       00000000   __GOTT_BASE__ + 0
00080c14  00000601 R_MIPS_16         00000000   __GOTT_INDEX__ + 0
0008141c  00000002 R_MIPS_32                    80c5c
00081800  00000002 R_MIPS_32                    80c5c
00081804  00000002 R_MIPS_32                    81800
00081808  00000502 R_MIPS_32         00081808   dglobal + 0
0008180c  00000202 R_MIPS_32         00000000   dexternal + 0
00081428  00000a02 R_MIPS_32         00081c00   x + 0
00000000  00000000 R_MIPS_NONE                  0
00000000  00000000 R_MIPS_NONE                  0

Adjust regular GOT entry counting then to take .got.plt entries into
account, removing a regression from the commit referred:

mips-vxworks  -FAIL: VxWorks shared library test 1
mipsel-vxworks  -FAIL: VxWorks shared library test 1

MIPS/LD/testsuite: Adapt VxWorks segment matching for PR ld/20815 fix

Adjust segment addresses in the program header dump to account for the
inclusion of the program headers in the segment, removing a regression
from commit 1a9ccd70f9a7 ("Fix the linker so that it will not silently
generate ELF binaries with invalid program headers.  Fix readelf to
report such invalid binaries."):

mips-vxworks  -FAIL: VxWorks executable test 2 (dynamic)
mipsel-vxworks  -FAIL: VxWorks executable test 2 (dynamic)

TIC6X/GAS: Work around array bounds compilation error

Work around a compilation error:

.../gas/config/tc-tic6x.c: In function 'tic6x_start_unwind_section':
.../gas/config/tc-tic6x.c:4632:17: error: offset '16' outside bounds of constant string [-Werror=array-bounds]
 4632 |       text_name += strlen (".gnu.linkonce.t.");
      |       ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

observed with GCC 10.

IA-64/GAS: Work around format truncation compilation errors

Work around compilation errors:

.../gas/config/tc-ia64.c: In function 'declare_register_set':
.../gas/config/tc-ia64.c:5375:41: error: '%u' directive output may be truncated writing between 1 and 10 bytes into a region of size 8 [-Werror=format-truncation=]
 5375 |       snprintf (name, sizeof (name), "%s%u", prefix, i);
      |                                         ^~
.../gas/config/tc-ia64.c:5375:38: note: directive argument in the range [0, 4294967294]
 5375 |       snprintf (name, sizeof (name), "%s%u", prefix, i);
      |                                      ^~~~~~
.../gas/config/tc-ia64.c:5375:7: note: 'snprintf' output 2 or more bytes (assuming 11) into a destination of size 8
 5375 |       snprintf (name, sizeof (name), "%s%u", prefix, i);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

observed with GCC 10.  Pick 16 for a round 64-bit stack frame size.

aarch64: GICv5 hypervisor control system registers

This patch adds support for hypervisor control registers on AArch64,
available via the Generic Interrupt Controller v5 feature, and enabled
via the +gcie flag.

- ich_apr_el2
- ich_contextr_el2
- ich_hfgitr_el2
- ich_hfgrtr_el2
- ich_hfgwtr_el2
- ich_hppir_el2 (RO)
- ich_ppi_activer[0,1]_el2
- ich_ppi_dvir[0,1]_el2
- ich_ppi_enabler[0,1]_el2
- ich_ppi_pendr[0,1]_el2
- ich_ppi_priorityr[0,15]_el2
- ich_vctlr_el2
- ich_vmcr_el2

aarch64: GICv5 PPI system registers

This patch adds support for PPI registers on AArch64, available via the
Generic Interrupt Controller v5 feature, and enabled via the +gcie flag.

- icc_ppi_cactiver[0,1]_el1
- icc_ppi_cpendr[0,1]_el1
- icc_ppi_enabler[0,1]_el1
- icc_ppi_hmr[0,1]_el1 (RO)
- icc_ppi_priorityr[0,15]_el1
- icc_ppi_sactiver[0,1]_el1
- icc_ppi_spendr[0,1]_el1

Also, the new system register 'icc_ppi_priorityr8_el1' clashed with the
encoding of 's3_0_c12_c15_0' used in a test for the generic syntax of
system registers using mrs and msr.
This patch replaces 's3_0_c12_c15_0' in the test by an unused encoding:
s3_7_c0_c15_0.

aarch64: GICv5 CPU interface system registers

This patch adds support for 13 new AArch64 system registers for the CPU
interface, which are enabled on using Generic Interrupt Controller v5
(+gcie flag) feature:
- 7 R/W registers: ICC_APR_EL1, ICC_APR_EL3, ICC_CR0_EL1, ICC_CR0_EL3
  ICC_ICSR_EL1, ICC_PCR_EL1, ICC_PCR_EL3.
- 6 RO registers: ICC_DOMHPPIR_EL3, ICC_HAPR_EL1, ICC_HPPIR_EL1,
  ICC_HPPIR_EL3, ICC_IAFFIDR_EL1, ICC_IDR0_EL1.

Note: the already-existing ID_AA64PFR2_EL1 register is required by the
GICv5 feature.

gas: aarch64: Add instructions for GICv5

Add new instructions from the Generic Interrupt Controller, GICv5,
extension. These instructions are aliases to system instructions and are
the following:

* gic <operation>, <reg>
* gicr <reg>, <operation>
* gsb <operation>

gas: aarch64: Add flag for GICv5

Generic Interrupt Controller v5, GICv5, adds new system registers
and system instructions. These are enabled with the +gcie flag, where
gcie stands for GICv5 (Generic Interrupt Controller) CPU Interrupt
Extension.

libsframe: testsuite: make test names unique

Previous commit 4dc07bf6 missed making some of the testnames in encode-1
unique.

libsframe/testsuite/
PR libsframe/33437
* libsframe.encode/encode-1.c: Update test name to ensure they
are unique.

gdb/python: add Corefile.mapped_files method

Add a new Corefile.mapped_files method which returns a list of
gdb.CorefileMappedFile objects.

Each gdb.CorefileMappedFile object represents a file that was mapped
into the process when the core file was created.

A gdb.CorefileMappedFile has attributes:

  + filename  -- A string, the name of the mapped file.
  + build_id -- A string or None, the build-id of the mapped file if
                GDB could find it (None if not).
  + is_main_executable -- A boolean, True if this mapping is the main
                          executable.
  + regions -- A list containing the regions of this file that were
               mapped into the process.

The 'regions' list is a list of gdb.CorefileMappedFileRegion objects,
each of these objects has the following attributes:

  + start -- the start address within the inferior.
  + end -- the end address within the inferior.
  + file_offset -- the offset within the mapped file for this mapping.

There are docs and tests.

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

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

gdb: make structured core file mappings processing global

In corelow.c, within core_target::build_file_mappings, we have code
that wraps around a call to gdbarch_read_core_file_mappings and
provides more structure to the results.

Specifically, gdbarch_read_core_file_mappings calls a callback once
for every region of every mapped file.  The wrapper code groups all of
the mappings for one file into an instance of 'struct mapped_file',
this allows all of the mapped regions to be associated with the
build-id and filename of a file.

In the next commit I plan to make this information available via the
Python API, and so I need to allow access to this structured wrapping
outside of corelow.c.

This commit renames 'struct mapped_file' to 'struct core_mapped_file'
and moves the struct into gdbcore.h.  Then a new global function
gdb_read_core_file_mappings is created into which I move the code to
build the structured data.

Then corelow.c is updated to call gdb_read_core_file_mappings.

This commit does not extend the Python API, that is for the next
commit.

There should be no user visible changes after this commit.

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

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

gdb/python: introduce gdb.Corefile API

This commit starts adding some core file related features to the
Python API.

In this initial commit I've tried to keep the changes as small as
possible for easy review.

There's a new Python class gdb.Corefile, which represents a loaded
core file.  This API doesn't allow the user to create their own
gdb.Corefile objects, a core file must be loaded using the 'core-file'
command, then a gdb.Corefile object can be obtained by querying the
inferior in which the core file was loaded.

There's a new attribute gdb.Inferior.corefile, this is None when no
core file is loaded, or contains a gdb.Corefile object if a core file
has been loaded.

Currently, the gdb.Corefile object has one attribute, and one method,
these are:

  gdb.Corefile.filename -- the file name of the loaded core file.

  gdb.Corefile.is_valid() -- indicates if a gdb.Corefile object is
  valid or not.  See notes below.

A gdb.Corefile object is only valid while the corresponding core file
is loaded into an inferior.  Unloading the core file, or loading a
different one will cause a gdb.Corefile object to become invalid.  For
example:

  (gdb) core-file /tmp/core.54313
  ... snip ...
  (gdb) python core=gdb.selected_inferior().corefile
  (gdb) python print(core)
  <gdb.Corefile inferior=1 filename='/tmp/core.54313'>
  (gdb) python print(core.is_valid())
  True
  (gdb) core-file
  No core file now.
  (gdb) python print(core)
  <gdb.Corefile (invalid)>
  (gdb) python print(core.is_valid())
  False
  (gdb)

In order to track changes to the core file, there is a new observable
'core_file_changed', which accounts for the changes in corelow.c,
observable,c, and observable.h.  Currently, this observable is not
visible as a Python event.

I chose to access the core file via the inferior even though the core
file BFD object is actually stored within the program_space.  As such,
it might seem that the natural choice would be to add the attribute as
gdb.Progspace.corefile.

For background reading on my choice, please see:

  https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com

This patch was never merged, it is still on my backlog, but the
observation in that work is that some targets are not really
shareable.  For example, the core_target (corelow.c) stores
information about the loaded core file within the target instance.  As
such, each target instance represents a single loaded core file.

Except that the BFD part of the core file is stored in the
program_space, which is a little weird.

During review, Tom made the observation, that maybe we should
investigate moving the core file BFD into the core_target.  I'm
inclined to agree with this as a direction of travel.

All this leaves us with two observations:

  1. Currently, loading a core file into an inferior, then using
     'add-inferior' will try to share the core_target between
     inferiors.  This is broken, and can trigger GDB crashes.  The
     obvious fix, without reworking core_target, is just to prevent
     this sharing, making core_target per-inferior.

  2. Having the core file information split between the core_target
     instance, and the BFD stored in the program_space is a little
     weird, and is really just historical.  Planning for a future
     where the BFD is also stored in the core_target might be wise.

So, if we imagine that the BFD is (one day) moved into the
core_target, and that the core_target really becomes non-shareable,
then it is, I think, clearer that the corefile attribute should live
on the gdb.Inferior object, not the gdb.Progspace object.

There's testing for all the functionality added in this commit.

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

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

Make location expressions be code in DWARF assembler

Currently the DWARF assembler implements manual parsing for location
expressions.  With a recent refactoring, this lead to the use of
[subst] in a number of places.

Following the same logic as the DW_AT_* change, this patch changes
location expressions to simply be nested Tcl code.  This avoids the
need for subst and also allows more complex logic, should that ever be
needed.

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

Store the "uplevel" target in DWARF assembler

This changes the DWARF assembler to store the desired "uplevel" frame
in Dwarf::assemble.  This frame is then used in the relevant "uplevel"
invocations in the assembler.

This is primarily useful for the next patch, but it also seems
somewhat cleaner in general to me, as the implementation can now be
refactored without worrying too much about introducing new stack
frames.

More "return" cleanup in gdb.ada

I found some more spots in gdb.ada where a "return" has a value but
does not need one.  This patch cleans these up.

Most of these would be eliminated by the old "critical" idea, if I
ever got around to finishing that...

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

gdb: tidy RISC-V part in gdb/Makefile.in and gdb/configure.tgt

I noticed that the length of line in gdb/configure.tgt was more than
80 lines, so I straightened it out. Also, in gdb/Makefile.in newly added
file riscv-linux-canonicalize-syscall-gen.c was missed in ALLDEPFILES,
so I added it there. And the last change: one more file
riscv-linux-canonicalize-syscall-gen.o was not in alphabetical order.

alpha-ecoff: check archive element size

If we run out of file before decompression finishes, the archive is
broken.  Don't allow the buffer to be returned with uninitialised data.

* coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Return an
error if the full element size can't be decompressed.

vms-alpha: integer overflow

image_offset takes values from section vma then increments when
filling out section data.  Avoid signed integer overflow.

* vms-alpha.c (struct vms_private_data_struct): Make image_offset
unsigned.

segv in debug_write_type

In commit 6c3458a8b7ee I claimed that u.kenum is always non-NULL,
which is true for debug_make_enum_type, but not for enums made by
debug_make_undefined_tagged_type.  Fix that oversight

PR 32829
* debug.c (debug_write_type): Handle NULL u.kenum.
(debug_type_samep): Likewise.

readelf reloc range check

A fuzzed object file hit this sanitizer error.
readelf.c:16764:9: runtime error: pointer index expression with base
0x6dd4491e1590 overflowed to 0xe7af96d4491e17a1

The same could occur in any of the IN_RANGE reloc checks, where the
reloc address is calculated as "start + r_offset" then compared
against "start" and "end".  So don't do that.  Compare r_offset
against the memory size, first.

* readelf.c (IN_RANGE): Delete.
(in_range): New inline funcion.
(target_specific_reloc_handling): Replace "end" param with
"size".  Update uses.  Replace IN_RANGE with in_range.
(apply_relocations): Delete "end" variable.  Update
target_specific_reloc_handling calls and replace IN_RANGE.
Avoid pointer overflow.

msp430: extended_dst disassembly

This avoids a gcc-14.2 bug reporting an "error: null destination
pointer" on an sprintf buffer that is not NULL.  Don't ask me why this
happens to work.

* msp430-dis.c (msp430_singleoperand): Don't overprint op or
comm for extended_dst.

Automatic date update in version.in

Rename "fp" in ctfread.c

Earlier reviews pointed out that "fp" is a poor choice of name in
ctfread.c.  Nick suggested "dict" instead, so this patch makes this
change.

Rework domain choices in ctfread.c

Another patch I am working on induced some failures in CTF tests.
Looking into this, I found that ctfread.c seems to largely work by
accident.  In particular, it often chooses the wrong domain for a
symbol.

In CTF, I believe there are 4 kinds of symbols: types, variables,
functions, and "data objects" (which IIUC may be either a variable or
a function).

ctfread.c was examining the type-kind of a variable and sometimes
treating one as a type.  add_stt_entries and
ctf_psymtab_add_stt_entries only ever used VAR_DOMAIN (but are called
for functions, which should be in FUNCTION_DOMAIN).  And
ctf_psymtab_type_cb sometimes used VAR_DOMAIN, but is only called for
types, and so should only ever use TYPE_DOMAIN or STRUCT_DOMAIN.

This patch cleans all this up, based on my understanding of the
situation.  This passes the existing tests, and also works with my
aforementioned yet-to-be-submitted patch as well.

Finally, I renamed new_symbol because it is only used for type
symbols.

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

Fix name checks in ctfread.c

I noticed that ctfread.c could create a symbol with the name "".  This
happens because a couple of spots check that a name is not NULL -- but
libctf never returns such names.  Instead check the string contents.

I left the NULL checks in for robustness.

Note that other spots in ctfread.c already do check the contents of
the name.  I changed these to avoid strlen and instead check the first
character.

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

Remove ctf_tid_key

ctfread.c creates two per-objfile registry keys.  However, one is
sufficient.  This patch combines the two.

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

Remove unnecessary call to set_tid_type

ctfread.c:read_typedef_type calls set_tid_type twice, but the second
call is unnecessary.

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

Stack allocate buildsym_compunit in ctfread.c

ctfread.c uses raw "new" and "delete", but for an object that could
just as easily be stack allocated.

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

Remove ctf_per_tu_data::pss

The field ctf_per_tu_data::pss is unused and can be removed.

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

Use gdb::unordered_map in ctfread.c

This changes ctfread.c to use gdb::unordered_map rather than hashtab.
This simplifies the code.

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

[gdb/testsuite, tclint] Fix lib/gdb.exp

[gdb/testsuite, tclint] Fix lib/aarch64-scalable.exp

[gdb/testsuite, tclint] Fix lib/aarch64.exp

[gdb/testsuite, tclint] Fix lib/mi-support.exp

[gdb/testsuite, tclint] Fix lib/dwarf.exp

[gdb/testsuite, tclint] Fix lib/gen-perf-test.exp

[gdb/testsuite, tclint] Fix lib/pascal.exp

[gdb/testsuite, tclint] Fix lib/gdbserver-support.exp

[gdb/testsuite, tclint] Fix lib/prelink-support.exp

[gdb/testsuite, tclint] Fix lib/trace-support.exp

[gdb/testsuite, tclint] Fix lib/future.exp

[gdb/testsuite, tclint] Fix lib/perftest.exp

[gdb/testsuite, tclint] Fix lib/selftest-support.exp

[gdb/testsuite, tclint] Fix lib/cp-support.exp

[gdb/testsuite, tclint] Fix lib/gdb-utils.exp

[gdb/testsuite, tclint] Fix lib/check-test-names.exp

[gdb/testsuite, tclint] Fix lib/rust-support.exp

[gdb/testsuite, tclint] Fix lib/prompt.exp

[gdb/testsuite, tclint] Fix lib/objc.exp

[gdb/testsuite, tclint] Fix lib/jit-elf-helpers.exp

[gdb/testsuite, tclint] Fix lib/go.exp