fbsd-nat: Add missing spaces.

No functional change, just style fixes.

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

gprofng: 30089 [display text] Invalid number of threads

The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example, dlopen@GLIBC_2.34,
dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc.
We have to interpose each of the functions because we don't know
which version of libC will be used during profiling.
Historically, we have used three versions of scripts (mapfile.aarch64-Linux,
mapfile.amd64-Linux, mapfile.intel-Linux).
Three are not needed. One is enough

The fixes below include:
 - merged all version symbols into one version script.
 - added new version symbols which are defined in latest versions of libC.
 - removed unused defines and duplicated code.
 - added the DCL_FUNC_VER macro to define the version symbols.

Tested on x86_64 and aarch64 (OL8/OL9). No regression.

gprofng/ChangeLog
2023-03-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30089
* libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.*
* libcollector/configure.ac: Delete GPROFNG_VARIANT.
* src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h
* libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER).
Remove unused defines.
* libcollector/dispatcher.c: Interpose functions from libC.
Clean up the old code.
* libcollector/iotrace.c: Likewise.
* libcollector/libcol_util.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/libgprofng.ver: New file.
* libcollector/Makefile.in: Rebuild.
* libcollector/configure: Rebuild.
* libcollector/mapfile.aarch64-Linux: Removed.
* libcollector/mapfile.amd64-Linux: Removed.
* libcollector/mapfile.intel-Linux: Removed.
* libcollector/mapfile.sparc-Linux: Removed.
* libcollector/mapfile.sparcv9-Linux: Removed.

linux-nat: introduce pending_status_str

I noticed that some debug log output printing an lwp's pending status
wasn't considering lp->waitstatus.  This fixes it, by introducing a
new pending_status_str function.

Also fix the comment in gdb/linux-nat.h describing
lwp_info::waitstatus and details the description of lwp_info::status
while at it.

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

displaced step: pass down target_waitstatus instead of gdb_signal

This commit tweaks displaced_step_finish & friends to pass down a
target_waitstatus instead of a gdb_signal.  This is needed because a
patch later in the step-over-{thread-exit,clone] series will want to
make displaced_step_buffers::finish handle
TARGET_WAITKIND_THREAD_EXITED.  It also helps with the
TARGET_WAITKIND_THREAD_CLONED patch later in that same series.

It's also a bit more logical this way, as we don't have to pass down
signals when the thread didn't actually stop for a signal.  So we can
also think of it as a clean up.

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

[gdb/testsuite] Fix gdb.stabs/exclfwd.exp for remote host

Fix test-case gdb.stabs/exclfwd.exp for remote host using include_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.stabs/weird.exp for remote host

Fix test-case gdb.stabs/weird.exp for remote host by not using an absolute
destfile argument to gdb_remote_download, which doesn't work well with remotedir.

[gdb/testsuite] Fix gdb.gdb/unittest.exp for remote host

Fix test-case gdb.gdb/unittest.exp for remote host, by:
- disabling the completion tests if readline is not used, and
- not using with_gdb_cwd $dir for remote host (because it does
  not support changing to ".").

Tested on x86_64-linux.

[gdb/testsuite] Skip do_self_tests on remote host

In do_self_tests we try to find out the location of the gdb to debug, which
will then be copied and renamed to xgdb.

In principle, the host board specifies the location of GDB, on host.

With remote host, we could upload that gdb from host to build/target, but we
would miss the data directory (which is listed as the reason to skip
do_self_tests for remote target).

We could fix that by instead taking the gdb from build instead, but that
wouldn't work with installed testing.

It seems easier to just skip this on remote host.

It could be made to work for the "[is_remote host] && [is_remote target]
&& host == target" scenario (see board local-remote-host-native.exp), but
that doesn't seem worth the effort.

Tested on x86_64-linux.

Change symbol::line to unsigned int

A user here at AdaCore noticed that, when debugging a certain program,
a stack frame reported line 34358, where it should have been line
99894.

After debugging a bit, I discovered:

(top) p (99894 & ~65536)
$60 = 34358

That line, symbol::line is too narrow.

This patch widens the member and changes all the uses that currently
use the narrower type.

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

Fix 128-bit integer bug in Ada

While working on 128-bit integer support, I found one spot in Ada that
needed a fix as well.

Use gdb_gmp for scalar arithmetic

This changes gdb to use scalar arithmetic for expression evaluation.

I suspect this patch is not truly complete, as there may be code paths
that still don't correctly handle 128-bit integers.  However, many
things do work now.

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

Use value_true in value_equal and value_less

Both value_equal and value_less use value_as_long to check a
presumably boolean result of calling value_binop.  However,
value_binop in this case actually returns an int as wide as its
arguments, and this approach can then fail for integers wider than
LONGEST.  Instead, rewrite this in a form that works for any size
integer.

Simplify binop_promote

binop_promote currently only handles integer sizes up to
builtin_long_long.  However, this may not handle 128-bit types.
Simplify this code, unify the C and non-C (but not OpenCL, as I don't
know how to test this) cases, and handle 128-bit integers as well.

This still doesn't exactly follow C or C++ rules.  This could be
implemented, but if so, I think it makes more sense as a C-specific
expression node.

Add value_as_mpz and value_from_mpz

This adds the two new functions, value_as_mpz and value_from_mpz,
useful for manipulation values via gdb_mpz.

Add truncation mode to gdb_mpz

This renames gdb_mpz::safe_export to export_bits, and adds a new flag
to export a truncated value.  This is needed by value arithmetic.

Avoid a copy in gdb_mpz::safe_export

Currently, gdb_mpz::safe_export will always make a copy of *this.
However, this copy isn't always needed.  This patch makes this code
slightly more efficient, by avoiding the copy when possible.

Add many operators to gdb_mpz

This adds many operator overloads and other useful methods to gdb_mpz.
This is preparation for using this class for scalar arithmetic in gdb
expression evaluation.

Populate seen_names hash in cooked_index_shard::do_finalize

Hannes pointed out that cooked_index_shard::do_finalize never
populates the seen_names hash table.  This patch adds the necessary
store.  This reduces memory use a little for "gdb gdb":

(before) Space used: 28909568 (+0 for this command)
(after)  Space used: 28884992 (+0 for this command)

What this means, btw, is that in gdb there are not many symbols that
are both mentioned in many CUs and that also require name
canonicalization.  It's possible this would differ in other programs.

[gdb/testsuite] Fix gdb.asm/asm-source.exp for remote host

Fix test-case gdb.asm/asm-source.exp for remote host using
host_standard_output_file and gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/imported-unit-bp-c.exp for remote host

Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a
downloaded source file.

Tested on x86_64-linux.

[gdb/testsuite] Unsupport gdb.dwarf2/gdb-add-index-symlink.exp for remote host

Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote
host, because the current implementation of gdb_ensure_index doesn't support it.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/gdb-index-cxx.exp for remote host

Fix test-case gdb.dwarf2/gdb-index-cxx.exp for remote host using
host_standard_output_file.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp for remote host

Fix test-case gdb.dwarf2/enqueued-cu-base-addr.exp for remote host by using
$testfile instead $binfile.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/gdb-index.exp on remote host

Fix test-case gdb.dwarf2/gdb-index.exp on remote host using
gdb_remote_download and host_standard_output_file.

Also declare the test-case unsupported with readnow.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp for remote host

Fix test-case gdb.dwarf2/per-bfd-sharing.exp for remote host using
gdb_remote_download.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix quoting issue in gdb.base/index-cache.exp

For test-case gdb.base/index-cache.exp and remote host, this:
...
lassign [remote_exec host sh "-c \"rm $cache_dir/*.gdb-index\""] ret
...
gives us:
...
Executing on host: sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index    (timeout = 300)
builtin_spawn -ignore SIGHUP sh -c rm /tmp/tmp.m3L7m2AVkL/*.gdb-index^M
rm: missing operand^M
Try 'rm --help' for more information.^M
FAIL: gdb.dwarf2/per-bfd-sharing.exp: couldn't remove files in temporary cache dir
...

Fix this using quote_for_host.  Likewise in gdb.dwarf2/per-bfd-sharing.exp.

Tested on x86_64-linux.

[gdb/testsuite] Fix quoting issues in gdb.dwarf2 for remote host

A few test-cases in gdb.dwarf2 use something like:
...
  additional_flags=\"-DFOO=BAR + 10\"
...
which doesn't work on remote host.

Fix this by introducing a new proc quote_for_host that also works for remote
host, such that we have:
...
  additional_flags=[quote_for_host -DFOO=BAR + 10]
...

Tested on x86_64-linux.

[gdb/testsuite] Fix have_index for remote host

Proc have_index is mostly used with $binfile, which gives problems
for remote host.

Fix this by using "file tail" on the proc argument.

Tested on x86_64-linux.

[gdb/testsuite] Add missing include_file in gdb.dwarf/*.exp

[gdb/testsuite] Add test-case gdb.dlang/dlang-start-2.exp

For test-case gdb.dlang/dlang-start.exp, I run into:
...
UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
...

My distro has no support for gdc, but I'd like to have the test-case
running and passing, so let's rewrite the test-case using dwarf assembly
and add it alongside (rather than replacing it, because it's good to use
actual compiler output if we have it available).

My distro does have a package providing dmd, so let's mimic that debug info in
the dwarf assembly.  This gives us:
...
(gdb) start ^M
Temporary breakpoint 1 at 0x4004ab^M
Starting program: dlang-start-2 ^M
^M
Temporary breakpoint 1, 0x00000000004004ab in _Dmain ()^M
...

The "_Dmain ()" should probably be "D main", I've filed PR30276 about that.

Also add a "show language" to check that we automatically set the language
correctly to D.

Note that the dwarf assembly also describes main, otherwise the test-case
doesn't function as regression test for commit 47fe57c9281 ("Fix "start" for
D, Rust, etc").

Tested on x86_64-linux.

Tidy tc-ppc.c XCOFF auxent access

It's better not to drill down into u.auxent but instead use a pointer
to the combined_entry_type.  That way the fix_scnlen field is
available, and no one looking at the codes needs to wonder whether
coffsymbol (symbol_get_bfdsym (sym))->native[i + 1] is the same
auxent.

* config/tc-ppc.c (ppc_frob_symbol): Tidy XCOFF auxent access.
(ppc_adjust_symtab): Likewise.

Remove coff_pointerize_aux table_end param

I'm fairly certain the table_end checks are redundant now.  This
patch reverts commit 334d4ced42d3.

* coffgen.c (coff_pointerize_aux): Remove table_end parameter.
(coff_get_normalized_symtab): Adjust to suit.

Use stdint types in coff internal_auxent

long is a poor choice of type to store 32-bit values read from
objects files by H_GET_32.  H_GET_32 doesn't sign extend so tests like
that in gdb/coffread.c for "negative" values won't work if long is
larger than 32 bits.  If long is 32-bit then code needs to be careful
to not accidentally index negative array elements.  (I'd rather see a
segfault on an unmapped 4G array index than silently reading bogus
data.)  long is also a poor choice for x_sect.s_scnlen, which might
have 64-bit values.  It's better to use unsigned exact width types to
avoid surprises.

I decided to change the field names too, which makes most of this
patch simply renaming.  Besides that there are a few places where
casts are no longer needed, and where printf format strings or tests
need adjusting.

include/
* coff/internal.h (union internal_auxent): Use unsigned stdint
types.  Rename l fields to u32 and u64 as appropriate.
bfd/
* coff-bfd.c,
* coff-rs6000.c,
* coff64-rs6000.c,
* coffcode.h,
* coffgen.c,
* cofflink.c,
* coffswap.h,
* peXXigen.c,
* xcofflink.c: Adjust to suit internal_auxent changes.
binutils/
* rdcoff.c: Adjust to suit internal_auxent changes.
gas/
* config/obj-coff.h,
* config/tc-ppc.c: Adjust to suit internal_auxent changes.
gdb/
* coffread.c,
* xcoffread.c: Adjust to suit internal_auxent changes.
ld/
* pe-dll.c: Adjust to suit internal_auxent changes.

Set proper union selector tag

* coff-bfd.c (bfd_coff_get_auxent): After converting sym pointer
to an index, reset the union tag.

coffgrok access of u.auxent.x_sym.x_tagndx.p

u.auxent.x_sym.x_tagndx is a union.  The p field is only valid when
fix_tag is set.  This patch fixes code in coffgrok.c that accessed the
field without first checking fix_tag, and removes a whole lot of code
validating bogus pointers to prevent segfaults (which no longer
happen, I checked the referenced PR 17512 testcases).  The patch also
documents this in the fix_tag comment, makes is_sym a bitfield, and
sorts the selecter fields a little.

bfd/
* coffcode.h (combined_entry_type): Make is_sym a bitfield.
Sort and comment on union selectors.
* libcoff.h: Regenerate.
binutils/
* coffgrok.c (do_type): Make aux a combined_entry_type.  Test
fix_tag before accessing u.auxent.x_sym.x_tagndx.p.  Remove
now unnecessary pointer bounds checking.

Duplicate DW_AT_call_file leak

When given two or more DW_AT_call_file for a given function we
currently leak the concat memory.

* dwarf2.c (scan_unit_for_symbols): Don't leak on duplicate
DW_AT_call_file.

XCOFF sanity check

* coffcode.h (coff_pointerize_aux_hook): Sanity check
x_csect.x_scnlen against raw_syment_count.

Add an option to the gold linker to put its version string into the .comment section.

  PR 30187
  * options.h (class General_options): Add enable-linker-version.
  * layout.cc (Layout::create_gold_note): If linker-version is enabled put the version string into the .comment section.

[gdb/testsuite] Handle missing gdc in gdb.dlang/dlang-start.exp

On openSUSE Leap 15.4, I get:
...
Running gdb.dlang/dlang-start.exp ...
gdb compile failed, default_target_compile: Can't find gdc.
UNTESTED: gdb.dlang/dlang-start.exp: failed to prepare
...

Fix this by:
- introducing a new proc can_compile, and
- requiring "can_compile d" in the test-case,
such that I have instead:
...
Running gdb.dlang/dlang-start.exp ...
UNSUPPORTED: gdb.dlang/dlang-start.exp: require failed: can_compile d
...

Tested on x86_64-linux, on openSUSE Leap 15.4 and Fedora 37.

[gdb/testsuite] Remove superfluous pid in temp files

While trying to use gdb_can_simple_compile with a d program, I ran into:
...
/data/vries/gdb/f37/build/gdb/testsuite/temp/105856/can_compile_d-105856.d: \
  error: module 'can_compile_d-105856' has non-identifier characters in \
  filename, use module declaration instead
...

The d compiler has a problem with the filename can_compile_d-105856.d, which
contains the pid.  The pid is added by gdb_simple_compile:
...
    set obj [standard_temp_file $name-[pid].$postfix]
...
but it's unnecessary because standard_temp_file already uses the pid.

Fix this by removing "[pid]" in all calls to standard_temp_file.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Introduce allow_dap_tests

Simon pointed out that with gdb.dap/*.exp and target board
native-gdbserver, we run into problems.

I see for each test-case:
...
+++ run
Traceback (most recent call last):
  File "startup.py", line 146, in exec_and_log
    output = gdb.execute(cmd, from_tty=True, to_string=True)
gdb.error: Don't know how to run.  Try "help target".
...

Likewise with target board native-extended-gdbserver.

Fix this by:
- adding a new proc allow_dap_tests,
- using it in all the gdb.dap tests, and
- bailing out if GDBFLAGS/INTERNAL_GDBFLAGS contains
  "set auto-connect-native-target off".

Tested on x86_64-linux.

Reported-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

Automatic date update in version.in

Preserve name of range types

The type-allocation patches introduced a small regression that was
picked up by the AdaCore internal test suite.  Previously, the name of
a range type was preserved by resolve_dynamic_range, but now it is
not.  This patch changes this code to preserve the name.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>

Implement repl evaluation for DAP

The evaluate command supports a "context" parameter which tells the
adapter the context in which an evaluation occurs.  One of the
supported values is "repl", which we took to mean evaluation of a gdb
command.  That is what this patch implements.

Note that some gdb commands probably will not work correctly with the
rest of the protocol.  For example if the user types "continue",
confusion may result.

This patch requires the earlier patch to fix up scopes in DAP.

[gdb/symtab] Fix line number of static const class member

Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there
was a silent regression on openSUSE Leap 15.4 for test-case
gdb.cp/m-static.exp, from:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /home/vries/tmp.local-remote-host-native/m-static.h:^M
8:      const int gnu_obj_4::everywhere;^M
(gdb)
...
to:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8:      const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8:      const int gnu_obj_4::everywhere;^M
(gdb)
...

Another regression was found due to that commit, and it was fixed in commit
99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by
limiting the scope of the fix in the original commit.

Fix this regression by yet further limiting the scope of that fix, making sure
that this bit in dwarf_decode_lines is executed again for m-static1.cc:
...
  /* Make sure a symtab is created for every file, even files
     which contain only variables (i.e. no code with associated
     line numbers).  */
...

Tested on x86_64-linux.

PR symtab/30265
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265

libctf: get the offsets of fields of unnamed structs/unions right

We were failing to add the offsets of the containing struct/union
in this case, leading to all offsets being relative to the unnamed
struct/union itself.

libctf/
PR libctf/30264
* ctf-types.c (ctf_member_info): Add the offset of the unnamed
member of the current struct as necessary.
* testsuite/libctf-lookup/unnamed-field-info*: New test.

libctf: fix a comment typo

ctf_dedup's intern() function does not return a dynamically allocated
string, so I just spent ten minutes auditing for obvious memory leaks
that couldn't actually happen.  Update the comment to note what it
actually returns (a pointer into an atoms table: i.e. possibly not
a new string, and not so easily leakable).

libctf/
* ctf-dedup.c (intern): Update comment.

libctf: work around an uninitialized variable warning

GCC 11+ complains that sym is uninitialized in ctf_symbol_next.  It
isn't, but it's not quite smart enough to figure that out (it requires
domain-specific knowledge of the state of the ctf_next_t iterator
over multiple calls).

libctf/
* ctf-lookup.c (ctf_symbol_next): Initialize sym to a suitable
value for returning if never reset during the function.

libctf: fix assertion failure with no system qsort_r

If no suitable qsort_r is found in libc, we fall back to an
implementation in ctf-qsort.c.  But this implementation routinely calls
the comparison function with two identical arguments. The comparison
function that ensures that the order of output types is stable is not
ready for this, misinterprets it as a type appearing more that once (a
can-never-happen condition) and fails with an assertion failure.

Fixed, audited for further instances of the same failure (none found)
and added a no-qsort test to my regular testsuite run.

libctf/:
PR libctf/30013
* ctf-dedup.c (sort_output_mapping): Inputs are always equal to
themselves.

Fix race in DAP startup

Internal AdaCore DAP testing on Windows has had occasional failures
that show:

    assert threading.current_thread() is _dap_thread

I think this is a race in DAP startup: the _dap_thread global is only
set on return from start_thread, but it seems possible that the thread
itself could already run and encounter a @in_dap_thread decorator.

This patch fixes the problem by setting the global before running any
of the code in the new thread.  This also lets us remove a FIXME.

aarch64: Check for valid inferior thread/regcache before reading pauth registers

There were reports of gdb throwing internal errors when calling
inferior_thread ()/get_current_regcache () on a system with
Pointer Authentication enabled.

In such cases, gdb produces the following backtrace:

../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0xaaaae04a571f gdb_internal_backtrace_1
../../../repos/binutils-gdb/gdb/bt-utils.c:122
0xaaaae04a57f3 _Z22gdb_internal_backtracev
../../../repos/binutils-gdb/gdb/bt-utils.c:168
0xaaaae0b52ccf internal_vproblem
../../../repos/binutils-gdb/gdb/utils.c:401
0xaaaae0b5310b _Z15internal_verrorPKciS0_St9__va_list
../../../repos/binutils-gdb/gdb/utils.c:481
0xaaaae0e24b8f _Z18internal_error_locPKciS0_z
../../../repos/binutils-gdb/gdbsupport/errors.cc:58
0xaaaae0a88983 _Z15inferior_threadv
../../../repos/binutils-gdb/gdb/thread.c:86
0xaaaae0956c87 _Z20get_current_regcachev
../../../repos/binutils-gdb/gdb/regcache.c:428
0xaaaae035223f aarch64_remove_non_address_bits
../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572
0xaaaae03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm
../../../repos/binutils-gdb/gdb/gdbarch.c:3109
0xaaaae0a692d7 memory_xfer_partial
../../../repos/binutils-gdb/gdb/target.c:1620
0xaaaae0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm
../../../repos/binutils-gdb/gdb/target.c:1684
0xaaaae0a69e9f target_read_partial
../../../repos/binutils-gdb/gdb/target.c:1937
0xaaaae0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml
../../../repos/binutils-gdb/gdb/target.c:1977
0xaaaae0a69937 _Z18target_read_memorymPhl
../../../repos/binutils-gdb/gdb/target.c:1773
0xaaaae08be523 ps_xfer_memory
../../../repos/binutils-gdb/gdb/proc-service.c:90
0xaaaae08be6db ps_pdread
../../../repos/binutils-gdb/gdb/proc-service.c:124
0x40001ed7c3b3 _td_fetch_value
/build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115
0x40001ed791ef td_ta_map_lwp2thr
/build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194
0xaaaae07f4473 thread_from_lwp
../../../repos/binutils-gdb/gdb/linux-thread-db.c:413
0xaaaae07f6d6f _ZN16thread_db_target4waitE6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../../repos/binutils-gdb/gdb/linux-thread-db.c:1420
0xaaaae0a6b33b _Z11target_wait6ptid_tP17target_waitstatus10enum_flagsI16target_wait_flagE
../../../repos/binutils-gdb/gdb/target.c:2586
0xaaaae0789cf7 do_target_wait_1
../../../repos/binutils-gdb/gdb/infrun.c:3825
0xaaaae0789e6f operator()
../../../repos/binutils-gdb/gdb/infrun.c:3884
0xaaaae078a167 do_target_wait
../../../repos/binutils-gdb/gdb/infrun.c:3903
0xaaaae078b0af _Z20fetch_inferior_eventv
../../../repos/binutils-gdb/gdb/infrun.c:4314
0xaaaae076652f _Z22inferior_event_handler19inferior_event_type
../../../repos/binutils-gdb/gdb/inf-loop.c:41
0xaaaae07dc68b handle_target_event
../../../repos/binutils-gdb/gdb/linux-nat.c:4206
0xaaaae0e25fbb handle_file_event
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:573
0xaaaae0e264f3 gdb_wait_for_event
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:694
0xaaaae0e24f9b _Z16gdb_do_one_eventi
../../../repos/binutils-gdb/gdbsupport/event-loop.cc:217
0xaaaae080f033 start_event_loop
../../../repos/binutils-gdb/gdb/main.c:411
0xaaaae080f1b7 captured_command_loop
../../../repos/binutils-gdb/gdb/main.c:475
0xaaaae0810b97 captured_main
../../../repos/binutils-gdb/gdb/main.c:1318
0xaaaae0810c1b _Z8gdb_mainP18captured_main_args
../../../repos/binutils-gdb/gdb/main.c:1337
0xaaaae0338453 main
../../../repos/binutils-gdb/gdb/gdb.c:32
---------------------
../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

We also see failures across the testsuite if the tests get executed on a target
that has native support for the pointer authentication feature. But
gdb.base/break.exp and gdb.base/access-mem-running.exp are two examples of
tests that run into errors and internal errors.

This issue started after commit d88cb738e6a7a7179dfaff8af78d69250c852af1, which
enabled more broad use of pointer authentication masks to remove non-address
bits of pointers, but wasn't immediately detected because systems with native
support for pointer authentication are not that common yet.

The above crash happens because gdb is in the middle of handling an event,
and do_target_wait_1 calls switch_to_inferior_no_thread, nullifying the
current thread.  This means a call to inferior_thread () will assert, and
attempting to call get_current_regcache () will also call inferior_thread (),
resulting in an assertion as well.

target_has_registers was one function that seemed useful for detecting these
types of situation where we don't have a register cache. The problem with that
is the inconsistent state of inferior_ptid, which is used by
target_has_registers.

Despite the call to switch_to_no_thread in switch_to_inferior_no_thread from
do_target_wait_1 in the backtrace above clearing inferior_ptid, the call to
ps_xfer_memory sets inferior_ptid momentarily before reading memory:

static ps_err_e
ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr,
                gdb_byte *buf, size_t len, int write)
{
  scoped_restore_current_inferior restore_inferior;
  set_current_inferior (ph->thread->inf);

  scoped_restore_current_program_space restore_current_progspace;
  set_current_program_space (ph->thread->inf->pspace);

  scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid);
  inferior_ptid = ph->thread->ptid;

  CORE_ADDR core_addr = ps_addr_to_core_addr (addr);

  int ret;
  if (write)
    ret = target_write_memory (core_addr, buf, len);
  else
    ret = target_read_memory (core_addr, buf, len);
  return (ret == 0 ? PS_OK : PS_ERR);
}

Maybe this shouldn't happen, or maybe it is just an unfortunate state to be
in. But this prevents the use of target_has_registers to guard against the
lack of registers, since, although current_thread_ is still nullptr,
inferior_ptid is valid and is not null_ptid.

There is another crash scenario after we kill a previously active inferior, in
which case the gdbarch will still say we support pointer authentication but we
will also have no current thread (inferior_thread () will assert etc).

If the target has support for pointer authentication, gdb needs to use
a couple (or 4, for bare-metal) mask registers to mask off some bits of
pointers, and for that it needs to access the registers.

At some points, like the one from the backtrace above, there is no active
thread/current regcache because gdb is in the middle of doing event handling
and switching between threads.

Simon suggested the use of inferior_ptid to fetch the register cache, as
opposed to relying on the current register cache.  Though we need to make sure
inferior_ptid is valid (not null_ptid), I think this works nicely.

With inferior_ptid, we can do safety checks along the way, making sure we have
a thread to fetch a register cache from and checking if the thread is actually
stopped or running.

The following patch implements this idea with safety checks to make sure we
don't run into assertions or errors.  If any of the checks fail, we fallback to
using a default mask to remove non-address bits of a pointer.

I discussed with Pedro the possibility of caching the mask register values
(which are per-process and can change mid-execution), but there isn't a good
spot to cache those values. Besides, the mask registers can change constantly
for bare-metal debugging when switching between exception levels.

In some cases, it is just not possible to get access to these mask registers,
like the case where threads are running. In those cases, using a default mask
to remove the non-address bits should be enough.

This can happen when we let threads run in the background and then we attempt
to access a memory address (now that gdb is capable of reading memory even
with threads running).  Thus gdb will attempt to remove non-address bits
of that memory access, will attempt to access registers, running into errors.

Regression-tested on aarch64-linux Ubuntu 20.04.

Tidy string_ptr increment

* peicode.h (pe_ILF_make_a_symbol): Use sprintf output to
increment string_ptr to end of new string.

Tidy dwarf1 cached section contents

* dwarf1.c (_bfd_dwarf1_cleanup_debug_info): New function.
* libbfd-in.h (_bfd_dwarf1_cleanup_debug_info): Declare.
* elf.c (_bfd_elf_close_and_cleanup): Call it.
* elf-bfd.h (struct elf_obj_tdata): Make dwarf1_find_line_info
a void*.
* libbfd.h: Regenerate.

[gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument

In proc mi_expect_stop there's a proc argument reason that's handled like so:
...
set r "reason=\"$reason\","
...

That's fine for say:
...
set reason "foo"
...
for which this evaluates to:
...
set r "reason=\"foo\","
...

But there are more complex uses, for instance:
...
set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
...
which evaluates to:
...
set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...

Note how in this reason argument, the first two '\"' seems to form a pair
surrounding ',disp=', which is not the case, which is confusing.

Fix this by only adding the quotes in mi_expect_stop if the string doesn't
already contain quotes, such that we have the more readable:
...
set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/m-static.exp regression on Ubuntu 20.04

In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I
needed to change ".*/" into "(.*/)?" in:
...
gdb_test "info variable everywhere" \
    "File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;"
...

However, due to the fact that I got this output:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8:      const int gnu_obj_4::everywhere;^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M
8:      const int gnu_obj_4::everywhere;^M
...
I decided to make the matching somewhat stricter, to make sure that the two
matched lines were subsequent.

The commit turned out to be more strict than intended, and caused a regression
on Ubuntu 20.04, where the output was instead:
...
(gdb) info variable everywhere^M
All variables matching regular expression "everywhere":^M
^M
File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M
8:      const int gnu_obj_4::everywhere;^M
...

At that point I realized I'm looking at a bug (filed as PR symtab/30265),
which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu
20.04 for readnow, but not for native.

Before my commit, the test-case passed whether the bug manifested or not.

After my commit, the test-case only passed when the bug manifested.

Fix the test-case regression by reverting to the situation before the commit:
pass whether the bug manifests or not.  We could add an xfail for the PR, but
I'm expecting a fix soon, so that doesn't look worth the effort.

Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with
native and readnow.

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

[gdb/dap] Add logging of ignored lines

This input sequence is accepted by DAP:
...
{"seq": 4, "type": "request", "command": "configurationDone"}Content-Length: 84
...

This input sequence has the same effect:
...
{"seq": 4, "type": "request", "command": "configurationDone"}ignorethis
Content-Length: 84
...
but the 'ignorethis' part is silently ignored.

Log the ignored bit, such that we have:
...
READ: <<<{"seq": 4, "type": "request", "command": "configurationDone"}>>>
WROTE: <<<{"request_seq": 4, "type": "response", "command": "configurationDone"
, "success": true}>>>
+++ run
IGNORED: <<<b'ignorethis'>>>
...

Automatic date update in version.in

Fix minor grammar issue in python.texi

I noticed a minor grammar problem in the 'GDB/MI Commands In Python'
node of the manual.  I'm checking in this patch to correct it.

Add support to readelf for the PT_OPENBSD_MUTABLE segment type.

binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type.
include  * elf/common.h (PT_OPENBSD_MUTABLE): Define.

[gdb/testsuite] Use gdb_remote_download in allow_opencl_tests

Simon reported that doing:
...
$ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
...
could run into:
...
ERROR: remote_download to target of \
  /data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
  cp: cannot create regular file 'opencl_kernel.cl': File exists
...

Fix this by using gdb_remote_download (instead of plain remote_download) in
allow_opencl_test, which takes care of:
- downloading to a location which is safe for parallel testing, by
  using standard_output_file, and
- cleaning up the downloaded file, meaning we can remove the corresponding
  "remote_file target delete ${clprogram}" lines in allow_opencl_test.

Tested on x86_64-linux.

Reported-by: Simon Marchi <simon.marchi@efficios.com>

bfd: aarch64: Optimize BTI stubs PR30076

Don't insert a second stub if the target is already compatible with
an indirect branch.

bfd: aarch64: Fix stubs that may break BTI PR30076

Insert two stubs in a BTI enabled binary when fixing long calls: The
first is near the call site and uses an indirect jump like before,
but it targets the second stub that is near the call target site and
uses a direct jump.

This is needed when a single stub breaks BTI compatibility.

The stub layout is kept fixed between sizing and building the stubs,
so the location of the second stub is known at build time, this may
introduce padding between stubs when those are relaxed.  Stub layout
with BTI disabled is unchanged.

bfd: aarch64: Refactor stub sizing code

elfNN_aarch64_size_stubs has grown big, so factor out the call stub
related code before adding new logic there.

gdb/riscv: add systemtap support

This commit is initial support for SystemTap for RISC-V Linux.  The
following two tests exercise SystemTap functionality, and are showing
many failures, which are all fixed by this commit:

  gdb.cp/exceptprint.exp
  gdb.base/stap-probe.exp

One thing I wasn't sure about is if the SystemTap support should be
Linux specific, or architecture specific.  For aarch64, arm, ia64, and
ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c
file, while for amd64, i386, and s390 the implementation lives in
ARCH-tdep.c.  I have no idea which of these is the better choice -- or
maybe both choices are correct in the right circumstances, and I'm
just not aware of how to choose between them.

Anyway, for this patch I selected riscv-tdep.c (though clearly, moving
the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a
more appropriate location).

The stap-probe.exp file tests immediate, register, and register
indirect operands, all of which appear to be working fine with this
commit.  The generic expression support doesn't appear to be
architecture specific, so I'd expect that to work fine too.

Automatic date update in version.in

gdb: remove gdbarch_displaced_step_fixup_p

The comment on the gdbarch_displaced_step_fixup gdbarch method
indicates that this method is optional and that GDB will perform some
default if this method is not supplied.  As such we define a predicate
gdbarch_displaced_step_fixup_p.

It may have been true at one point that the fixup method was optional,
but it is no longer true.  If this method is not defined and GDB tries
to complete a displaced step, then GDB is going to crash.

Additionally the gdbarch_displaced_step_fixup_p predicate is not used
anywhere in GDB.

In this commit I have removed the gdbarch_displaced_step_fixup_p
predicate, and I have updated the validation check for the
gdbarch_displaced_step_fixup method; if the
gdbarch_displaced_step_copy_insn method is defined then the fixup
method must also be defined.

I believe I've manually checked all the current places where
gdbarch_displaced_step_copy_insn is defined and they all also define
the fixup method, so this change should cause no problems for anyone.

There should be no user visible changes after this commit.

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

Remove unnecessary cast

I found an upcast from template_symbol to symbol.  This was necessary
long ago, but since symbols use inheritance now, it is not.  This
patch removes it.  Tested by rebuilding.

gdb/testsuite: adjust test cases to previous "maintenance info line-table" change

Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show
relocated addresses again") changed the format of that command, but
failed to adjust some test cases that relied on it.  This patch fixes
it.

The failures fixed are:

    FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
    FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
    FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table

Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c

[gdb/testsuite] Fix gdb.cp/cp-relocate.exp for remote host

Fix test-case gdb.cp/cp-relocate.exp for remote host using
gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/annota{2,3}.exp for native-extended-gdbserver

When running test-cases gdb.cp/annota{2,3}.exp with target board
native-extended-gdbserver, we run into a few FAILs, due to the test-cases
trying to match inferior output together with gdb output.

Fix this by ignoring the inferior output in this case.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/*.exp for remote host

Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
include_file.

Tested on x86_64-linux.

gdb: make "maintenance info line-table" show relocated addresses again

Commit 1acc9dca423f ("Change linetables to be objfile-independent")
changed "maintenance info line-table" to print unrelocated addresses
instead of relocated.  This breaks a few tests on systems where that
matters.  The ones I see are:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
    FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
    FAIL: gdb.base/async.exp: stepi&
    FAIL: gdb.base/async.exp: nexti&
    FAIL: gdb.base/async.exp: finish&

These tests run "maintenance info line-table" to record the address of
some lines, and then use these addresses in expected patterns.  It
therefore expects these addresses to match the runtime addresses,
therefore the relocated addresses.

Add back the relocated addresses, next to the unrelocated addresses,
like so:

    INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END
    0      6      0x0000555555555119 0x0000000000001119 Y
    1      7      0x000055555555511d 0x000000000000111d Y
    2      8      0x0000555555555123 0x0000000000001123 Y
    3      END    0x0000555555555125 0x0000000000001125 Y

The unrelocated addresses can always be useful trying to map this
information with a DWARF info dump.

Adjust the is_stmt_addresses proc in the testsuite to match the new
output.

Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf

coff_get_normalized_symtab bfd_release

We can't free "internal" on errors, since bfd_coff_swap_sym_in may
call bfd_alloc.  For example, _bfd_XXi_swap_sym_in may even create new
sections, which use bfd_alloc'd memory.  If "internal" is freed, all
more recently bfd_alloc'd memory is also freed.

* coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
error.

Automatic date update in version.in

Remove unnecessary memsets in sframe-dump.c

* sframe-dump.c (dump_sframe_func_with_fres): Don't memset temp.

Sanity check coff-sh and coff-mcore sym string offset

* coff-mcore.c (coff_mcore_relocate_section): Sanity check sym
string offset when setting up name for use by error messages.
* coff-sh.c (sh_relocate_section): Likewise.

PR17910 sym string offset check

As far as I can see the only place that sets obj_coff_strings without
setting obj_coff_strings_len is pe_ILF_build_a_bfd.  Fix that and we
can simplify the sym string offset check.  This is just a tidy.
pe_ILF_build_a_bfd doesn't create bad symbols and
_bfd_coff_read_string_table will always result in non-zero
obj_coff_strings_len when obj_coff_strings is non-NULL.

PR 17910
* coffgen.c (_bfd_coff_internal_syment_name): Always sanity
check sym string offset.
* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len.

PE fake section for C_SECTION syms

It's an odd thing to have objdump -x show a different section table
to objdump -h, but that can happen if swapping in symbols leads to
creating sections.  Setting SEC_LINKER_CREATED stops the display of
these sections, so that you get shown what is in the object file.

* peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on
fake section created for C_SECTION syms.  Don't zero asection
fields that are already zero.

XCOFF: use bfd_coff_close_and_cleanup

Free memory on closing bfds.  The COFF close_and_cleanup does more
work than _bfd_generic_close_and_cleanup (defined as
_bfd_archive_close_and_cleanup).

* coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as
_bfd_coff_close_and_cleanup.
* coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use
_bfd_coff_close_and_cleanup.

gas: expand_irp memory leaks

* macro.c (expand_irp): Free memory on error return paths.

x86: Check unbalanced braces in memory reference

Check unbalanced braces in memory reference to avoid assembler crash
caused by

commit e87fb6a6d0cdfc0e9c471b7825c20c238c2cf506
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Oct 5 09:16:24 2022 +0200

    x86/gas: support quoted address scale factor in AT&T syntax

PR gas/30248
* config/tc-i386.c (i386_att_operand): Check unbalanced braces
in memory reference.
* testsuite/gas/i386/i386.exp: Run pr30248.
* testsuite/gas/i386/pr30248.d: New file.
* testsuite/gas/i386/pr30248.err: Likewise.
* testsuite/gas/i386/pr30248.s: Likewise.

PowerPC: regression fix for reverse-finish command.

The recent commit:

  commit 2a8339b71f37f2d02f5b2194929c9d702ef27223
  Author: Carl Love <cel@us.ibm.com>
  Date:   Thu Mar 9 16:10:18 2023 -0500

   PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

   PPC64 multiple entry points, a normal entry point and an alternate entry
   point.  The alternate entry point is to setup the Table of Contents (TOC)
   register before continuing at the normal entry point.  When the TOC is
   already valid, the normal entry point is used, this is typically the case.
   The alternate entry point is typically referred to as the global entry
   point (GEP) in IBM.  The normal entry point is typically referred to as
   the local entry point (LEP).
     .....

Is causing regression failures on on PowerPC platforms.  The regression
failures are in tests:

  gdb.reverse/finish-precsave.exp
  gdb.btrace/tailcall.exp
  gdb.mi/mi-reverse.exp
  gdb.btrace/step.exp
  gdb.reverse/until-precsave.exp
  gdb.reverse/finish-reverse.exp
  gdb.btrace/tailcall-only.exp

The issue is in gdb/infcmd.c, function finish_command.  The value of the
two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed
to SAL.PC.  However, SAL has just been declared.  The value of SAL.PC is
zero at this point.  The intialization of ALT_ENTRY_POINT and ENTRY_POINT
needs to be after the initialization of SAL.

This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT
variables to fix the regression failures.

The patch has been tested on Power10 and on X86.

[gdb/testsuite] Check remote_exec results in board files

Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is
checked.

Tested on x86_64-linux.

[gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.exp

In a recent commit I forgot to add a double quote before chmod here:
...
      remote_exec build $rsh_cmd chmod go-rx ."
...

Fix it by adding the missing double quote.

[gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.exp

Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp,
I don't see a relevant difference with the implementation of standard_file
in dejagnu.

Simplify the board by removing ${board}_file.

Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.

[gdb/testsuite] Use localhost instead of 127.0.0.1 for boards

Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1".

Use instead "localhost".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.xml/tdesc-regs.exp for remote host

Fix test-case gdb.xml/tdesc-regs.exp for remote host by using appropriate
filenames.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.xml/tdesc-reload.exp for remote host

Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate
filenames.

Tested on x86_64-linux.

[gdb/testsuite] Set remotedir in local-remote-host-native.exp

In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I
removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs
in test-case gdb.testsuite/board-sanity.exp.

Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for
a host board no longer make compilation fail due to commit 80d6c79866f
("[gdb/testsuite] Handle remotedir in remote_upload").

This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit
3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards").

Tested on x86_64-linux.

RISC-V: Fix disassemble fetch fail return value.

This bug reported in
https://sourceware.org/bugzilla/show_bug.cgi?id=30184
And discussed in
https://sourceware.org/pipermail/binutils/2023-February/126213.html

We also checked the implementation of return value in arm and mips.
So this patch changes the return value to -1, that can fix bugs and maintain
consistency with other architectures.

opcodes/ChangeLog:

        * riscv-dis.c (print_insn_riscv):Change the return value.

Remove .c header files from rs6000-aix-nat.c file

Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64
definitions are moved to ppc-tdep.h we no longer need to import these .c files.

Automatic date update in version.in

Remove some unnecessary includes from *-exp.y

I noticed a weird comment in one of the .y files, and then ended up
removing some unnecessary #includes from these files.

Tested by rebuilding.

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

Remove mi_version function

The mi_version function is unused, and I think it's better overall if
it is never used.  This patch removes it.  Tested by rebuilding.

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

Update python-helper.exp for type allocation changes

The type allocation changes introduced a failure in python-helper.exp
that I did not notice.  The bug is that, with these patches,
arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
This patch updates the test to allow this.

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

[gdb/testsuite] Handle remotedir in remote_upload

Dejagnu's remotedir implementation has support in remote_exec and
remote_download, but not remote_upload.

Consider the following scenario:
- downloading an executable to target,
- running it,
- uploading a file produced by the executable
while assuming remote target user remote-target with homedir
/home/remote-target and remotedir set to /home/remote-target/tmp.

Concretely, it looks like this:
...
 # binfile == "$outputs/gdb.abc/a.out"
 set target_binfile [remote_download target $binfile]
 # target_binfile == "/home/remote-target/tmp/a.out"
 remote_exec target $target_binfile
 # Running $target_binfile produced /home/remote-target/tmp/result.txt.
 set result [remote_upload target /home/remote-target/tmp/result.txt \
                 $outputs/gdb.abc/result.txt]
 # result == $outputs/gdb.abc/result.txt.
...

Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
overriding dejagnu's remote_upload, such that we can simplify the
remote_upload call to:
...
 set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
...

Tested on x86_64-linux.

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

gdb: fix crash during command completion

In some cases GDB will fail when attempting to complete a command that
involves a rust symbol, the failure can manifest as a crash.

The problem is caused by the completion_match_for_lcd object being
left containing invalid data during calls to cp_symbol_name_matches_1.

The first question to address is why we are calling a C++ support
function when handling a rust symbol.  That's due to GDB's auto
language detection for msymbols, in some cases GDB can't tell if a
symbol is a rust symbol, or a C++ symbol.

The test application contains symbols for functions which are
statically linked in from various rust support libraries.  There's no
DWARF for these symbols, so all GDB has is the msymbols built from the
ELF symbol table.

Here's the problematic symbol that leads to our crash:

    mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE
  demangled: core::str::<impl str>::parse

As an msymbol this is initially created with language auto, then GDB
eventually calls symbol_find_demangled_name, which loops over all
languages calling language_defn::sniff_from_mangled_name, the first
language that can demangle the symbol gets assigned as the language
for that symbol.

Unfortunately, there's overlap in the mangled symbol names,
some (legacy) rust symbols can be demangled as both rust and C++, see
cplus_demangle in libiberty/cplus-dem.c where this is mentioned.

And so, because we check the C++ language before we check for rust,
then the msymbol is (incorrectly) given the C++ language.

Now it's true that is some cases we might be able to figure out that a
demangled symbol is not actually a valid C++ symbol, for example, in
our case, the construct '::<impl str>::' is not, I believe, valid in a
C++ symbol, we could look for ':<' and '>:' and refuse to accept this
as a C++ symbol.

However, I'm not sure it is always possible to tell that a demangled
symbol is rust or C++, so, I think, we have to accept that some times
we will get this language detection wrong.

If we accept that we can't fix the symbol language detection 100% of
the time, then we should make sure that GDB doesn't crash when it gets
the language wrong, that is what this commit addresses.

In our test case the user tries to complete a symbol name like this:

  (gdb) complete break pars

This results in GDB trying to find all symbols that match 'pars',
eventually we consider our problematic symbol, and we end up with a
call stack that looks like this:

  #0  0x0000000000f3c6bd in strncmp_iw_with_mode
  #1  0x0000000000706d8d in cp_symbol_name_matches_1
  #2  0x0000000000706fa4 in cp_symbol_name_matches
  #3  0x0000000000df3c45 in compare_symbol_name
  #4  0x0000000000df3c91 in completion_list_add_name
  #5  0x0000000000df3f1d in completion_list_add_msymbol
  #6  0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on
  #7  0x0000000000658c08 in language_defn::collect_symbol_completion_matches
  #8  0x0000000000df54c9 in collect_symbol_completion_matches
  #9  0x00000000009d98fb in linespec_complete_function
  #10 0x00000000009d99f0 in complete_linespec_component
  #11 0x00000000009da200 in linespec_complete
  #12 0x00000000006e4132 in complete_address_and_linespec_locations
  #13 0x00000000006e4ac3 in location_completer

In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly
tries to match the demangled problematic symbol name against the user
supplied text ('pars').  Each time around the loop another component
of the symbol name is stripped off, thus, we check 'pars' against
these options:

  core::str::<impl str>::parse
  str::<impl str>::parse
  <impl str>::parse
  parse

As soon as we get a match the cp_symbol_name_matches_1 exits its loop
and returns.  In our case, when we're looking for 'pars', the match
occurs on the last iteration of the loop, when we are comparing to
'parse'.

Now the problem here is that cp_symbol_name_matches_1 uses the
strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for
skipping over template parameters.  This allows GDB to match the
symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'.
Inside strncmp_iw_with_mode GDB will record any template arguments
that it has skipped over inside the completion_match_for_lcd object
that is passed in as an argument.

And so, when GDB tries to match against '<impl str>::parse', the first
thing it sees is '<impl str>', GDB assumes this is a template argument
and records this as a skipped region within the
completion_match_for_lcd object.  After '<impl str>' GDB sees a ':'
character, which doesn't match with the 'pars' the user supplied, so
strncmp_iw_with_mode returns a value indicating a non-match.  GDB then
removes the '<impl str>' component from the symbol name and tries
again, this time comparing to 'parse', which does match.

Having found a match, then in cp_symbol_name_matches_1 we record the
match string, and the full symbol name within the
completion_match_result object, and return.

The problem here is that the skipped region, the '<impl str>' that we
recorded in the penultimate loop iteration was never discarded, its
still there in our returned result.

If we look at what the pointers held in the completion_match_result
that cp_symbol_name_matches_1 returns, this is what we see:

  core::str::<impl str>::parse
  |          \________/  |
  |               |      '--- completion match string
  |               '---skip range
  '--- full symbol name

When GDB calls completion_match_for_lcd::finish, GDB tries to create a
string using the completion match string (parse), but excluding the
skip range, as the stored skip range is before the start of the
completion match string, then GDB tries to do some weird string
creation, which will cause GDB to crash.

The reason we don't often see this problem in C++ is that for C++
symbols there is always some non-template text before the template
argument.  This non-template text means GDB is likely to either match
the symbol, or reject the symbol without storing a skip range.

However, notice, I did say, we don't often see this problem.  Once I
understood the issue, I was able to reproduce the crash using a pure
C++ example:

  template<typename S>
  struct foo
  {
    template<typename T>
    foo (int p1, T a)
    {
      s = 0;
    }

    S s;
  };

  int
  main ()
  {
    foo<int> obj (2.3, 0);
    return 0;
  }

Then in GDB:

  (gdb) complete break foo(int

The problem here is that the C++ symbol for the constructor looks like
this:

  foo<int>::foo<double>(int, double)

When GDB enters cp_symbol_name_matches_1 the symbols it examines are:

  foo<int>::foo<double>(int, double)
  foo<double>(int, double)

The first iteration of the loop will match the 'foo', then add the
'<int>' template argument will be added as a skip range.  When GDB
find the ':' after the '<int>' the first iteration of the loop fails
to match, GDB removes the 'foo<int>::' component, and starts the
second iteration of the loop.

Again, GDB matches the 'foo', and now adds '<double>' as a skip
region.  After that the '(int' successfully matches, and so the second
iteration of the loop succeeds, but, once again we left the '<int>' in
place as a skip region, even though this occurs before the start of
our match string, and this will cause GDB to crash.

This problem was reported to the mailing list, and a solution
discussed in this thread:

  https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html

The solution proposed here is similar to one proposed by the original
bug reported, but implemented in a different location within GDB.
Instead of placing the fix in strncmp_iw_with_mode, I place the fix in
cp_symbol_name_matches_1.  I believe this is a better location as it
is this function that implements the loop, and it is this loop, which
repeatedly calls strncmp_iw_with_mode, that should be resetting the
result object state (I believe).

What I have done is add an assert to strncmp_iw_with_mode that the
incoming result object is empty.

I've also added some other asserts in related code, in
completion_match_for_lcd::mark_ignored_range, I make some basic
assertions about the incoming range pointers, and in
completion_match_for_lcd::finish I also make some assertions about how
the skip ranges relate to the match pointer.

There's two new tests.  The original rust example that was used in the
initial bug report, and a C++ test.  The rust example depends on which
symbols are pulled in from the rust libraries, so it is possible that,
at some future date, the problematic symbol will disappear from this
test program.  The C++ test should be more reliable, as this only
depends on symbols from within the C++ source code.

Since I originally posted this patch to the mailing list, the
following patch has been merged:

  commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb
  Date:   Sun Mar 19 09:13:10 2023 -0600

      Use rust_demangle to fix a crash

This solves the problem of a rust symbol ending up in the C++ specific
code by changing the order languages are sorted.  However, this new
commit doesn't address the issue in the C++ code which was fixed with
this commit.

Given that the C++ issue is real, and has a reproducer, I'm still
going to merge this fix.  I've left the discussion of rust in this
commit message as I originally wrote it, but it should be read within
the context of GDB prior to commit 6e7eef72164c00d6a5a7.

Co-Authored-By: Zheng Zhan <zzlossdev@163.com>

x86: drop identifier_chars[]

It tries to resemble what's underlying is_part_of_name(), but doesn't
quite achieve that: '$' for example is unconditionally marked as part of
symbol names, but was included as identifier char for Intel syntax only.
Note that i386_att_operand() checks for the immediate prefix first, so
the wider coverage by starts_memory_operand() is has no real effect
there, but it does matter for something like

mov %fs:$dollar, %eax

which previously wasn't accepted (but which clearly is a memory
reference - there's no point in forcing people to parenthesize the
symbol name). Similarly including '%' as an identfier for Intel syntax
had no real significance to the rest of the assembler. If '%' was to be
valid in (unquoted) symbol names, LEX_PCT would need to be defined.

Note further that this also addresses the latent issue of a sub-target
defining LEX_AT or LEX_QM to zero: That would make '@' and/or '?' no
valid part of symbol names, but would have included them in what
is_identifier_char() considers a valid part of a name. (There's a minor
related issue which is actually being eliminated: te-interix.h allows
'@' only in the middle of symbol names, yet starts_memory_operand()
specifically looks at the first character of [possibly] a symbol name.)

In parse_real_register() there's no point also checking is_name_ender()
as at this point no character is marked solely LEX_END_NAME by any sub-
target. Checking is_name_beginner() is also pointless as the hash lookup
will fail anyway for a zero-length name.

While touching the check in parse_real_register() also drop the
"allow_naked_reg" part of the condition: This has only led to
inconsistent error messages.