sh4-linux segfaults running ld testsuite

Segmentation fault
FAIL: pr22269-1 (static pie undefined weak)
and others running "visibility (hidden undef)" tests

No code has any right to access bfd_link_hash_entry u.def without
first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.

* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
relocs in GOT unless symbol is defined.

PR30343 infrastructure

Make ldemul_before_plugin_all_symbols_read more useful.

* ldlang.c (lang_process): Move call to
ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
Allow backends to add to gc_sym_list before handling entry sym.
* ldelf.c (ldelf_before_plugin_all_symbols_read): Test
lto_plugin_active.

ubsan: signed integer overflow in display_debug_lines_raw

This one was caused by me unnecessarily promoting an "int adv" to
"int64_t adv".  The expression overflowing was 4259 + 9223372036854775807
with the left number being unsigned int.

* dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
with uint16_t and unsigned char with uint8_t.  Make li_line_base
an int8_t.
* dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.

Yet another out-of-memory fuzzed object

Do I care about out of memory conditions triggered by fuzzers?  Not
much.  Your operating system ought to be able to handle it by killing
the memory hog.  Oh well, this one was an element of a coff-alpha
archive that said it was a little less that 2**64 in size.  The
coff-alpha compression scheme expands at most 8 times, so we can do
better in bfd_get_file_size.

* bfdio.c (bfd_get_file_size): Assume elements in compressed
archive can only expand a maximum of eight times.
* coffgen.c (_bfd_coff_get_external_symbols): Sanity check
size of symbol table agains file size.

buffer overflow in print_symname

* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate
string sections.

libsframe: minor formatting fixes in sframe_encoder_write_fre

libsframe/
* sframe.c (sframe_encoder_write_fre): Formatting fixes for
  readability.

libsframe: use consistent function argument names

libsframe/
* sframe.c (sframe_decoder_get_header): Use consistent function
arg names.
(sframe_decoder_free): Likewise.
(sframe_encode): Use more appropriate var name.

sframe: correct some typos

include/
* sframe.h: Correct a typo.

libsframe/
* sframe.c: Likewise.

libsframe: use return type of bool for predicate functions

libsframe/
* sframe.c (sframe_header_sanity_check_p): Change return type to
bool.
(sframe_fre_sanity_check_p): Likewise.

gas: sframe: fix comment

gas: sframe: use ATTRIBUTE_UNUSED consistently

gas/
* gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
consistently.
(output_sframe): Likewise.
(sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.

Remove adjust_type_signedness

I happened across adjust_type_signedness, which may be used to modify
a type when printing an Ada value.  Modifying a type like this is a
bad idea -- they should normally be considered immutable.  Removing
this function still passes both the dejagnu and internal AdaCore
tests, though, so this patch drops it.

As this was reviewed internally, and only affect Ada, I am checking it
in.

Fix: readelf: loc_offset XX too big

  PR 30355
  * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section.

gas: document that get_symbol_name() can clobber the input buffer

Callers which want to make further parsing attempts at the buffer passed
to the function need to be aware that due to the potential of string
concatenation the input buffer may be altered in ways beyond what can be
undone by putting back at *input_line_pointer the character that the
function returns.

x86: parse_register() must not alter the parsed string

This reverts the code change done by 100f993c53a5 ("x86: Check
unbalanced braces in memory reference"), which wrongly identified
e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T
syntax") as the root cause of PR gas/30248. (The testcase is left in
place, no matter that it's at best marginally useful in that shape.)

The problem instead is that parse_register() alters the string handed to
it, thus breaking valid assumptions in subsequent parsing code. Since
the function's behavior is a result of get_symbol_name()'s, make a copy
of the incoming string before invoking that function.

Like for parse_real_register() follow the model of strtol() et al: input
string is const-qualified to signal that the string isn't altered, but
the returned "end" pointer is not const-qualified, requiring const to be
cast away (which generally is a bad idea, but the alternative would
again be more convoluted code).

x86: parse_real_register() does not alter the parsed string

Follow the model of strtol() et al - input string is const-qualified to
signal that the string isn't altered, but the returned "end" pointer is
not const-qualified, requiring const to be cast away (which generally is
a bad idea, but the alternative would be more convoluted code).

Updated Hungarian translation for the gprof directory

Automatic date update in version.in

gdb: re-format Python code with black 23

Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b

PowerPC: fix _Float128 type output string

PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float.  The issue is the DWARF information does not
distinguish between the two.  There have been proposals of how to extend
the DWARF information as discussed in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

but has not been fully implemented.

GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB.  The internal _Float128 type
name is printed rather then the user specified long double type.  This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround.  The workaround checks for "_Float128" name when reading the
base typedef from the die_info.  If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef.  The same is done for the complex long double typedef.

This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC.  It fixes one regression test failure in
gdb.base/complex-parts.exp.

The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float.  The
patch as also been tested on X86-64 with no new regression failures.

Symbols with GOT relocatios do not fix adjustbale

  gas
    * config/tc-loongarch.c (loongarch_fix_adjustable): Symbols with GOT relocatios do not fix adjustbale.
    * testsuite/gas/loongarch/macro_op_large_abs.d: Regenerated.
    * testsuite/gas/loongarch/macro_op_large_pc.d: Regenerated.
  ld
     * testsuite/ld-loongarch-elf/macro_op.d: Regenerated. -

Assembler Internal Docs: Describe handling of opcodes for relaxation a bit better.

RISC-V: Cache the latest mapping symbol and its boundary.

This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188

Current flow:
1) Scan any mapping symbol less than this instruciton.
2) If not found, did a backward search.

The flow seems not big issue, let run an example here:

$x:
0x0 a   <--- Found at step 1
0x4 b   <--- Not found in step 1, but found at step 2
0x8 c   <--- Not found in step 1, but found at step 2
$d
0x12 .word 1234 <-- Found at step 1

The instruciton didn't have the same address with mapping symbol will
still did backward search again and again.

So the new flow is:
1) Use the last mapping symbol status if the address is still within the range
   of the current mapping symbol.
2) Scan any mapping symbol less than this instruciton.
3) If not found, did a backward search.
4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
   and cache that.

Use the same example to run the new flow again:

$x:
0x0 a   <--- Found at step 2, the boundary is 0x12
0x4 b   <--- Cache hit at step 1, within the boundary.
0x8 c   <--- Cache hit at step 1, within the boundary.
$d
0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.

The disassemble time of the test cases has been reduced from ~20 minutes to ~4
seconds.

opcode/ChangeLog
PR 30282
* riscv-dis.c (last_map_symbol_boundary): New.
(last_map_state): New.
(last_map_section): New.
(riscv_search_mapping_symbol): Cache the result of latest
mapping symbol.

objdump use of uninitialised value in pr_string_field

PR 30365
* rdcoff.c (parse_coff_struct_type): Leave bitsize zero when no
auxents.

objdump buffer overflow in fetch_indexed_string

PR 30361
* dwarf.c (fetch_indexed_string): Sanity check string index.

Automatic date update in version.in

gprofng: 30360 Seg. Fault when application uses std::thread

We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example,

% nm -D /lib64/gprofng/libgp-collector.so  | grep thread_create@ | sort
000000000004b420 T pthread_create@GLIBC_2.34
000000000004b490 T pthread_create@GLIBC_2.17
000000000004b500 T pthread_create@GLIBC_2.2.5
000000000004b570 T pthread_create@GLIBC_2.1
000000000004b5e0 T pthread_create@GLIBC_2.0

Our library does not set the default version for symbols.
This is correct because we don't know which libC will be used.

gcc and g++ links differently the version symbols when the default version is
not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using
our pthread_create@GLIBC_2.0 by default.

The current implementation of the interposed functions is:
  If we are in our pthread_create@GLIBC_<NN>,
  we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call
  the same function from libC.
In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC.
We need to call the default version symbol from libC.

gprofng/ChangeLog
2023-04-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30360
* libcollector/iotrace.c: Find and call a default libC version symbol.
* libcollector/dispatcher.c: Likewise.
* libcollector/iotrace.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/collector.h (REAL_DCL): Remove an unused argument.

gprofng: Update documentation

This patch addresses bugzilla 29521:
Bug 29521 - [docs] man pages are not in the release tarball

The dependence on help2man to create the man pages has been eliminated.
All man pages are now written in Texinfo. Texi2pod and pod2man are used
to generate the man pages from the source.

The user guide has been significantly expanded. It also includes all
the man pages. These are formatted appropriately in the INFO, PDF, and
HTML formats.

The index in the user guide has been enhanced to include an overview
of all options and commands that have been documented so far.

The work on the documentation has not been completed, but this is
a significant step forward.

gprofng/ChangeLog
2023-04-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29521
* doc/Makefile.am: Build documentation.
* doc/gprofng.texi: Update documentation.
* doc/version.texi: Likewise.
* src/Makefile.am: Move the man pages generation to doc/Makefile.am.
* gp-display-html/Makefile.am: Likewise.
* doc/gp-archive.texi: New file.
* doc/gp-collect-app.texi: New file.
* doc/gp-display-html.texi: New file.
* doc/gp-display-src.texi: New file.
* doc/gp-display-text.texi: New file.
* doc/gp-macros.texi: New file.
* doc/gprofng_ug.texi: New file.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in" Rebuild.

Remove some unnecessary casts from ada-lang.c

I noticed some unnecessary casts to LONGEST in ada-lang.c.  This patch
removes the ones I think are very clearly not needed.  I'm checking
this in as obvious.

gdb/amdgpu: add follow fork and exec support

Prior to this patch, it's not possible for GDB to debug GPU code in fork
children or after an exec.  The amd-dbgapi target attaches to processes
when an inferior appears due to a "run" or "attach" command, but not
after a fork or exec.  This patch adds support for that, such that it's
possible to for an inferior to fork and for GDB to debug the GPU code in
the child.

To achieve that, use the inferior_forked and inferior_execd observers.

In the case of fork, we have nothing to do if `child_inf` is nullptr,
meaning that GDB won't debug the child.  We also don't attach if the
inferior has vforked.  We are already attached to the parent's address
space, which is shared with the child, so trying to attach would cause
problems.  And anyway, the inferior can't do anything other than exec or
exit, it certainly won't start GPU kernels before exec'ing.

In the case of exec, we detach from the exec'ing inferior and attach to
the following inferior.  This works regardless of whether they are the
same or not.  If they are the same, meaning the execution continues in
the existing inferior, we need to do a detach/attach anyway, as
amd-dbgapi needs to be aware of the new address space created by the
exec.

Note that we use observers and not target_ops::follow_{fork,exec} here.
When the amd-dbgapi target is compiled in, it will attach (in the
amd_dbgapi_process_attach sense, not the ptrace sense) to native
inferiors when they appear, but won't push itself on the inferior's
target stack just yet.  It only pushes itself if the inferior
initializes the ROCm runtime.  So, if a non-GPU-using inferior calls
fork, an amd_dbgapi_target::follow_fork method would not get called.
Same for exec.  A previous version of the code had the amd-dbgapi target
pushed all the time, in which case we could use the target methods.  But
we prefer having the target pushed only when necessary, it's less
intrusive when doing native debugging that doesn't involve the GPU.

Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: switch to right inferior in fetch_inferior_event

The problem explained and fixed in the previous patch could have also
been fixed by this patch.  But I think it's good change anyhow, that
could prevent future bugs, so here it is.

fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
of the process target of the inferior used to fetch the event.  The idea is
that the event handling code will need to do some target calls, so we want to
switch to an inferior that has target target.

However, you can have two inferiors that share a process target, but with one
inferior having an additional target on top:

        inf 1            inf 2
        -----            -----
                         another target
        process target   process target
        exec             exec

Let's say inferior 2 is selected by do_target_wait and returns an event that is
really synthetized by "another target".  This "another target" could be a
thread or record stratum target (in the case explained by the previous patch,
it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
layer).  fetch_inferior_event will then switch to the first inferior with
"process target", so inferior 1.  handle_signal_stop then tries to fetch the
thread's registers:

    ecs->event_thread->set_stop_pc
      (regcache_read_pc (get_thread_regcache (ecs->event_thread)));

This will try to get the thread's register by calling into the current target
stack, the stack of inferior 1.  This is problematic because "another target"
might have a special fetch_registers implementation.

I think it would be a good idea to switch to the inferior for which the
even was reported, not just some inferior of the same process target.
This will ensure that any target call done before we eventually call
context_switch will be done on the full target stack that reported the
event.

Not all events are associated to an inferior though.  For instance,
TARGET_WAITKIND_NO_RESUMED.  In those cases, some targets return
null_ptid, some return minus_one_ptid (ideally the expected return value
should be clearly defined / documented).  So, if the ptid returned is
either of these, switch to an arbitrary inferior with that process
target, as before.

Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: make regcache::raw_update switch to right inferior

With the following patch, which teaches the amd-dbgapi target to handle
inferiors that fork, we end up with target stacks in the following
state, when an inferior that does not use the GPU forks an inferior that
eventually uses the GPU.

    inf 1            inf 2
    -----            -----
                     amd-dbgapi
    linux-nat        linux-nat
    exec             exec

When a GPU thread from inferior 2 hits a breakpoint, the following
sequence of events would happen, if it was not for the current patch.

 - we start with inferior 1 as current
 - do_target_wait_1 makes inferior 2 current, does a target_wait, which
   returns a stop event for an amd-dbgapi wave (thread).
 - do_target_wait's scoped_restore_current_thread restores inferior 1 as
   current
 - fetch_inferior_event calls switch_to_target_no_thread with linux-nat
   as the process target, since linux-nat is officially the process
   target of inferior 2.  This makes inferior 1 the current inferior, as
   it's the first inferior with that target.
 - In handle_signal_stop, we have:

    ecs->event_thread->suspend.stop_pc
      = regcache_read_pc (get_thread_regcache (ecs->event_thread));

    context_switch (ecs);

   regcache_read_pc executes while inferior 1 is still the current one
   (because it's before the `context_switch`).  This is a problem,
   because the regcache is for a ptid managed by the amd-dbgapi target
   (e.g. (12345, 1, 1)), a ptid that does not make sense for the
   linux-nat target.  The fetch_registers target call goes directly
   to the linux-nat target, which gets confused.
 - We would then get an error like:

     Couldn't get extended state status: No such process.

   ... since linux-nat tries to do a ptrace call on tid 1.

GDB should switch to the inferior the ptid belongs to before doing the
target call to fetch registers, to make sure the call hits the right
target stack (it should be handled by the amd-dbgapi target in this
case).  In fact the following patch does this change, and it would be
enough to fix this specific problem.

However, I propose to change regcache to make it switch to the right
inferior, if needed, before doing target calls.  That makes the
interface as a whole more independent of the global context.

My first attempt at doing this was to find an inferior using the process
stratum target and the ptid that regcache already knows about:

      gdb::optional<scoped_restore_current_thread> restore_thread;
      inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
      if (inf != current_inferior ())
{
  restore_thread.emplace ();
  switch_to_inferior_no_thread (inf);
}

However, this caused some failures in fork-related tests and gdbserver
boards.  When we detach a fork child, we may create a regcache for the
child, but there is no corresponding inferior.  For instance, to restore
the PC after a displaced step over the fork syscall.  So
find_inferior_ptid would return nullptr, and
switch_to_inferior_no_thread would hit a failed assertion.

So, this patch adds to regcache the information "the inferior to switch
to to makes target calls".  In typical cases, it will be the inferior
that matches the regcache's ptid.  But in some cases, like the detached
fork child one, it will be another inferior (in this example, it will be
the fork parent inferior).

The problem that we witnessed was in regcache::raw_update specifically,
but I looked for other regcache methods doing target calls, and added
the same inferior switching code to raw_write too.

In the regcache constructor and in get_thread_arch_aspace_regcache,
"inf_for_target_calls" replaces the process_stratum_target parameter.
We suppose that the process stratum target that would be passed
otherwise is the same that is in inf_for_target_calls's target stack, so
we don't need to pass both in parallel.  The process stratum target is
still used as a key in the `target_pid_ptid_regcache_map` map, but
that's it.

There is one spot that needs to be updated outside of the regcache code,
which is the path that handles the "restore PC after a displaced step in
a fork child we're about to detach" case mentioned above.

regcache_test_data needs to be changed to include full-fledged mock
contexts (because there now needs to be inferiors, not just targets).

Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: add maybe_switch_inferior function

Add the maybe_switch_inferior function, which ensures that the given
inferior is the current one.  Return an instantiated
scoped_restore_current_thread object only we actually needed to switch
inferior.

Returning a scoped_restore_current_thread requires it to be
move-constructible, so give it a move constructor.

Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: remove regcache::target

The regcache class takes a process_stratum_target and then exposes it
through regcache::target.  But it doesn't use it itself, suggesting it
doesn't really make sense to put it there.  The only user of
regcache::target is record_btrace_target::fetch_registers, but it might
as well just get it from the current target stack.  This simplifies a
little bit a patch later in this series.

Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: add inferior_forked observable

In the upcoming patch to support fork in the amd-dbgapi target, the
amd-dbgapi target will need to be notified of fork events through an
observer, to attach itself (attach in the amd-dbgapi sense, not ptrace
sense) to the new inferior / process.

The reason that this can't be done through target_ops::follow_fork is
that the amd-dbgapi target isn't pushed on the inferior's target stack
right away.  It attaches itself to the process and only pushes itself on
its target stack if and when the inferior initializes the ROCm runtime.

If an inferior that is not using the ROCm runtime forks, we want to be
notified of it, so we can attach to the child, and catch if the child
starts using the ROCm runtime.

So, add a new observable and notify it in follow_fork_inferior.  It will
be used later in this series.

Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: pass execing and following inferior to inferior_execd observers

The upcoming patch to support exec in the amd-dbgapi target needs to
detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi
to the inferior continuing the execution.  They may or may not be the
same, depending on the `set follow-exec-mode` setting.  But even if they
are the same, we need to do the detach / attach dance.

With the current observable signature, the observers only receive the
inferior in which execution continues (the "following" inferior).

Change the signature to pass both inferiors, and update all existing
observers.

Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659
Reviewed-By: Pedro Alves <pedro@palves.net>

Add 128-bit integer support to the Ada parser

This adds support for 128-bit integers to the Ada parser.

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

Remove some Ada parser helper functions

These helper functions in the Ada parser don't seem all that
worthwhile to me, so this patch removes them.

Add overload of fits_in_type

This adds an overload of fits_in_type that accepts a gdb_mpz.  A
subsequent patch will use this.

Add 128-bit integer support to the Rust parser

This adds support for 128-bit integers to the Rust parser.

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

Convert long_const_operation to use gdb_mpz

This changes long_const_operation to use gdb_mpz for its storage.

Additions to gdb_mpz

In preparation for adding more 128-bit support to gdb, a few additions
to gdb_mpz are needed.

First, this adds a new 'as_integer_truncate' method.  This method
works like 'as_integer' but does not require the value to fit in the
target type -- it just truncates.

Second, gdb_mpz::export_bits is changed to handle the somewhat unusual
situation of zero-length types.  This can happen for a Rust '()' type;
but I think other languages have zero-bit integer types as well.

Finally, this adds some operator== overloads.

Make the .rsrc section read only.

  PR 30142
  * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
  * rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.

[gdb/symtab] Handle empty file name in .debug_line section

With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
 The File Name Table (offset 0x112, lines 1, columns 2):
  Entry Dir     Name
  0     1       (indirect line string, offset: 0x2d):
...

Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
  gdb/dwarf2/read.c:18716
18716     if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.

Note that the behaviour of read_direct_string has been present since repo
creation.

Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.

Tested on x86_64-linux.

Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357

Add support for the .gnu.sgstubs section to the linker for ARM/ELF based targets.

  PR 30354
  * emulparams/armelf.sh (OTHER_PLT_SECTIONS): Define in order to handle the .gnu.sgstubs section.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: accept script argument for mi_make_breakpoint_pending

This commit changes mi_make_breakpoint_pending to accept the 'script'
and 'times' arguments.

I've then added a new test that makes use of 'scripts' in
gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.

There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
argument -- previously this argument was being ignored, but is now
used.

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

gdb/testsuite: avoid {"} pattern in lib/mi-support.exp

Commit:

  commit c569a946f6925d3f210c3eaf74dcda56843350ef
  Date:   Fri Mar 24 10:45:37 2023 +0100

      [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument

Introduced the use of {"} in mi-support.exp.  There is absolutely
nothing wrong with this in any way.  However, this is causing my
editor to get the syntax highlighting of this file wrong after this
point.

Maybe the real answer is to use a better editor, or fix my current
editor.... but I'm hoping I can instead take the lazy approach of just
changing {"} to "\"", which is handled fine, and means exactly the
same as far as I understand it.

There should be no change in what is tested after this commit.

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

pauth: Create new feature string for pauth to prevent crashing older gdb's

Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever
a target reports the pauth feature string in the target description and also
provide additional register outside of gdb's known and expected feature
strings.

This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out
there that will crash on connection to the above targets.

QEMU has postponed inclusion of the pauth feature string in version 8, and
instead we agreed to use a new feature name to prevent crashing those older
gdb's.

Initially there was a plan to backport a trivial fix all the way to gdb 9, but
given QEMU's choice, this is no longer needed.

This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used
by all targets going forward, except native linux gdb and gdbserver, for
backwards compatibility with older gdb's/gdbserver's.

gdb/gdbserver will still emit the old feature string for Linux since it doesn't
report additional system registers and thus doesn't cause a crash of older
gdb's. We can revisit this in the future once the problematic gdb's are likely
no longer in use.

I've added some documentation to explain the situation.

debug registers: Add missing debug version entry for FEAT_Debugv8p8

The Arm Architecture Reference Manual defines debug version 0b1010 for
FEAT_Debugv8p8. This is used to identify valid hardware debug registers.

gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
teaches gdb about this new version.

No visible changes should happen as consequence of this patch, but in the
future gdb will be able to identify debug registers in newer hardware.

Regression-tested on aarch64-linux Ubuntu 20.04/22.04.

gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp

(1) Description of problem

In the current code, when execute the following test on LoongArch:

$make check-gdb TESTS="gdb.base/dump.exp"
```
FAIL: gdb.base/dump.exp: dump array as value, intel hex
FAIL: gdb.base/dump.exp: dump struct as value, intel hex
FAIL: gdb.base/dump.exp: dump array as memory, ihex
FAIL: gdb.base/dump.exp: dump struct as memory, ihex

```
These tests passed on the X86_64,

(2) Root cause

On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
so dump ihex test failed.

gdb.base/dump.exp has the following code to check 64-bit address

```
 # Check the address of a variable.  If it is bigger than 32-bit,
 # assume our target has 64-bit addresses that are not supported by SREC,
 # IHEX and TEKHEX.  We skip those tests then.
 set max_32bit_address "0xffffffff"
 set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
 if {${data_address} > ${max_32bit_address}} {
    set is64bitonly "yes"
}
```

We check the "&intarray" on different target as follow:

```
$gdb gdb/testsuite/outputs/gdb.base/dump/dump
...
(gdb) start
...

On X86_64:
(gdb) print /x &intarray
$1 = 0x404060

On LoongArch:
(gdb) print /x &intarray
$1 = 0x120008068
```
The variable address difference here is due to the link script
of linker.

```
On X86_64:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

On LoongArch:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
. = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;

```

(3) How to fix

Because 64-bit variable address out of range for IHEX, it's not an
functional problem for LoongArch. Refer to the handling of 64-bit
targets in this testsuite, use the "is64bitonly" flag to skip those
tests for the target has 64-bit addresses.

Signed-off-by: Hui Li <lihui@loongson.cn>
Approved-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

[gdb/testsuite] Add regression test for PR30325

Add regression tests for PR30325, one for the asm window and one for the
source window.

Use maint set tui-left-margin verbose to make the extend of the left margin
clear.

Tested on x86_64-linux.

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

Automatic date update in version.in

Avoid double-free with debuginfod

PR gdb/29257 points out a possible double free when debuginfod is in
use.  Aside from some ugly warts in the symbol code (an ongoing
issue), the underlying issue in this particular case is that elfread.c
seems to assume that symfile_bfd_open will return NULL on error,
whereas in reality it throws an exception.  As this code isn't
prepared for an exception, bad things result.

This patch fixes the problem by introducing a non-throwing variant of
symfile_bfd_open and using it in the affected places.

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

arc: Update ARC specific linker tests.

All the tests are designed for a little-endian ARC system. Thus,
update the arc predicate in arc.exp, improve the matching pattern for
linker relaxation test, and add linker scripts to nps-1x tests.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update ARC's CFI tests.

The double store/loads instructions (e.g. STD/LDD) are not baseline
ARC ISA.  The same holds for some short instructions.  Update the
tests to use base ARC ISA.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update GAS test

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

Preserve a few more bfd fields in check_format_matches

AOUT and COFF targets set symcount and start_address in their object_p
functions.  If these are used anywhere then it would pay to save and
restore them so that a successful match gets the values expected
rather than that for a later unsuccessful target match.

* format.c (struct bfd_preserve): Move some fields.  Add
symcount, read_only and start_address.
(bfd_preserve_save): Save..
(bfd_preserve_restore): ..and restore..
(bfd_reinit): ..and zero new fields.

Re: pe_ILF_object_p and bfd_check_format_matches

The last patch wasn't quite correct.  bfd_preserve_restore also needs
to handle an in-memory to file backed transition, seen in a testcase
ILF object matching both pei-arm-little and pei-arm-wince-little.
There the first match is saved in preserve_match, and restored at the
end of the bfd_check_format_matches loop making the bfd in-memory.  On
finding more than one match the function wants to restore the bfd back
to its original state with another bfd_preserve_restore call before
exiting with a bfd_error_file_ambiguously_recognized error.

It is also not correct to restore abfd->iostream unless the iovec
changes.  abfd->iostream is a FILE* when using cache_iovec, and if
the file has been closed and reopened the iostream may have changed.

* format.c (io_reinit): New function.
(bfd_reinit, bfd_preserve_restore): Use it.

Automatic date update in version.in

[gdb/tui] Revert workaround in tui_source_window::show_line_number

The m_digits member of tui_source_window is documented as having semantics:
...
  /* How many digits to use when formatting the line number.  This
     includes the trailing space.  */
...

The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source
code") started printing two trailing spaces instead:
...
-  xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
+  xsnprintf (text, sizeof (text), "%*d  ", m_digits - 1, lineno);
...

Now that PR30325 is fixed, this no longer has any effect.

Fix this by reverting to the original behaviour: print one trailing space
char.

Tested on x86_64-linux.

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

[gdb/tui] Fix left margin in disassembly window

With a hello world a.out, and maint set tui-left-margin-verbose on, we have
this disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│___ 0x555555555149 <main>           endbr64                │
│___ 0x55555555514d <main+4>         push   %rbp            │
│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
...
Note the space between "B+>" and 0x555555555151.  The space shows that a bit
of the left margin is not written, which is a problem because that location is
showing a character previously written, which happens to be a space, but also
may be something else, for instance a '[' as reported in PR tui/30325.

The problem is caused by confusion about the meaning of:
...
 #define TUI_EXECINFO_SIZE 4
...

There's the meaning of defining the size of this zero-terminated char array:
...
      char element[TUI_EXECINFO_SIZE];
...
which is used to print the "B+>" bit, which is 3 chars wide.

And there's the meaning of defining part of the size of the left margin:
...
  int left_margin () const
  { return 1 + TUI_EXECINFO_SIZE + extra_margin (); }
...
where it represents 4 chars.

The discrepancy between the two causes the space between "B+>" and
"0x555555555151".

Fix this by redefining TUI_EXECINFO_SIZE to 3, and using:
...
      char element[TUI_EXECINFO_SIZE + 1];
...
such that we have:
...
|B+>0x555555555151 <main+8>         lea    0xeac(%rip),%rax │
...

This changes the layout of the disassembly window back to what it was before
commit 9e820dec13e ("Use a curses pad for source and disassembly windows"),
the commit that introduced the PR30325 regression.

This also changes the source window from:
...
│___000005__{                                               |
...
to:
...
│___000005_{                                                |
...

Tested on x86_64-linux.

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

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

[gdb/tui] Add maint set/show tui-left-margin-verbose

The TUI has two types of windows derived from tui_source_window_base:
- tui_source_window (the source window), and
- tui_disasm_window (the disassembly window).

The two windows share a common concept: the left margin.

With a hello world a.out, we can see the source window:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│        5  {                                               │
│B+>     6    printf ("hello\n");                           │
│        7    return 0;                                     │
│        8  }                                               │
│        9                                                  │
│
...
where the left margin is the part holding "B+>" and the line number, and the
disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│    0x555555555149 <main>           endbr64                │
│    0x55555555514d <main+4>         push   %rbp            │
│    0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│    0x555555555158 <main+15>        mov    %rax,%rdi       │
...
where the left margin is just the bit holding "B+>".

Because the left margin contains some spaces, it's not clear where it starts
and ends, making it harder to observe problems related to it.

Add a new maintenance command "maint set tui-left-margin-verbose", that when
set to on replaces the spaces in the left margin with either '_' or '0',
giving us this for the source window:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│___000005__{                                               │
│B+>000006__  printf ("hello\n");                           │
│___000007__  return 0;                                     │
│___000008__}                                               │
...
and this for the disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│___ 0x555555555149 <main>           endbr64                │
│___ 0x55555555514d <main+4>         push   %rbp            │
│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
...

Note the space between "B+>" and 0x555555555151.  The space shows that a bit
of the left margin is not written, a problem reported as PR tui/30325.

Specifically, PR tui/30325 is about the fact that the '[' character from the
string "[ No Assembly Available ]" ends up in that same spot:
...
│B+>[0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
...
which only happens for certain window widths.

The new command allows us to spot the problem with any window width.

Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces
between line numbers and source code"), we have:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│___000005_ {                                               │
│B+>000006_   printf ("hello\n");                           │
│___000007_   return 0;                                     │
│___000008_ }                                               │
...
showing a similar problem at the space between '_' and '{'.

Tested on x86_64-linux.

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

Use SELF_CHECK in all unit tests

I noticed a few unit tests are using gdb_assert.  I think this was an
older style, before SELF_CHECK was added.  This patch switches them
over.

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

arc: remove faulty instructions

Clean not implemented ARC instruction from ARC instruction table.

Use 'require' with gnatmake_version_at_least

I found a couple of tests that check gnatmake_version_at_least using
"if" where "require" would be a little cleaner.  This patch converts
these.

MIPS: make mipsisa32 and mipsisa64 link more systematic

Introduce `static const struct mips_mach_extension mips_mach_32_64[]`
and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`,
to make mipsisa32 and mipsisa64 interlink more systemtic.

Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and
mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1),
so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64.

Note: R6 is not compatible with pre-R6.

bfd/ChangeLog:

* elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and
  mipsisa64 interlink more systematic.
  (mips_mach_32_64): new struct added.
  (mips_mach_extends_32_64): new function added.

Fix typos in the linker's documentation of the --enable-non-contiguous-regions option.

PR30326, uninitialised value in objdump compare_relocs

This is a fuzzing PR, with a testcase involving a SHF_ALLOC and
SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc
section.  BFD doesn't handle compressed relocation sections, with most
of the code reading relocs using sh_size (often no bfd section is
created) but in the case of SHF_ALLOC dynamic relocs we had some code
using the bfd section size.  This led to a mismatch, sh_size is
compressed, size is uncompressed, and from that some uninitialised
memory.  Consistently using sh_size is enough to fix this PR, but I've
also added tests to exclude SHF_COMPRESSED reloc sections from
consideration.

PR 30362
* elf.c (bfd_section_from_shdr): Exclude reloc sections with
SHF_COMPRESSED flag from normal reloc processing.
(_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude
SHF_COMPRESSED sections from consideration.  Use sh_size when
sizing to match slurp_relocs.
(_bfd_elf_canonicalize_dynamic_reloc): Likewise.
(_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size
plt relocs.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.

ubsan: dwarf2.c:2232:7: runtime error: index 16 out of bounds

Except it isn't out of bounds because space for a larger array has
been allocated.

* dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
(alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.

Fail of x86_64 AMX-COMPLEX insns (Intel disassembly)

x86_64-w64-mingw32 pads sections.

* testsuite/gas/i386/x86-64-amx-complex-intel.d: Don't fail
due to nop padding.

pe_ILF_object_p and bfd_check_format_matches

If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the
bfd from being file backed to in-memory.  This can have unfortunate
results for targets checked by bfd_check_format_matches after that
point as they will be matching against the created in-memory image
rather than the file.  bfd_preserve_restore also has a problem if it
flips the BFD_IN_MEMORY flag, because the flag affects iostream
meaning and should be set if using _bfd_memory_iovec.  To fix these
problems, save and restore iostream and iovec along with flags, and
modify bfd_reinit to make the bfd file backed again.  Restoring the
iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY
(part of BFD_FLAGS_SAVED) to be removed.
One more detail: If restoring from file backed to in-memory then the
bfd needs to be forcibly removed from the cache lru list, since after
the bfd becomes in-memory a bfd_close will delete the bfd's memory
leaving the lru list pointing into freed memory.

* cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here..
(bfd_cache_lookup_worker): ..rather than here.
(bfd_cache_close): Comment.
* format.c (struct bfd_preserve): Add iovec and iostream fields.
(bfd_preserve_save): Save them..
(bfd_preserve_restore): ..and restore them, calling
bfd_cache_close if the iovec differs.
(bfd_reinit): Add preserve param.  If the bfd has been flipped
to in-memory, reopen the file.  Restore flags.
* peicode.h (pe_ILF_cleanup): New function.
(pe_ILF_object_p): Return it.
* bfd.c (BFD_FLAGS_SAVED): Delete.
* bfd-in2.h: Regenerate.

Comment typo fix

Automatic date update in version.in

bfd: optimize bfd_elf_hash

The bfd_elf_hash loop is taken straight from the sysV document, but it
is poorly optimized. This refactoring removes about 5 x86 insns from
the 15 insn loop.

1) The if (..) is meaningless -- we're xoring with that value, and of
course xor 0 is a nop. On x86 (at least) we actually compute the xor'd
value and then cmov.  Removing the if test removes the cmov.

2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits
will be shifted out in the next iteration.  All we need to do is sink
a mask of those 4 bits out of the loop.

3) anding with 0xf0 after shifting by 24 bits can allow betterin
encoding on RISC ISAs than masking with '0xf0 << 24' before shifting.
RISC ISAs often require materializing larger constants.

bfd/
* elf.c (bfd_elf_hash): Refactor to optimize loop.
(bfd_elf_gnu_hash): Refactor to use 32-bit type.

gdb, doc: correct argument description for info connections/inferiors

It said for 'info inferiors' and 'info connections' that the argument
could be 'a space separated list of inferior numbers' which is correct
but incomplete.  In fact the arguments can be any space separated
combination of numbers and (ascending) ranges.

The beginning of the section now describes the ID list as a new keyword.

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

Replace an assertion in the dwarf code with a warning message.

  PR 30327
  * dwarf.c (read_and_display_attr_value): Warn if the number of views is greater than the number of locations.

Fix an illegal memorty access when running gprof over corrupt data.

  PR 30324
  * symtab.c (symtab_finalize): Only change the end address if dst has been updated.

Fix an attempt to allocate an excessive amount of memory when parsing a corrupt DWARF file.

  PR 30313
  * dwarf.c (display_debug_lines_decoded): Check for an overlarge number of files or directories.

Fix a potential illegal memory access when displaying corrupt DWARF information.

  PR 30312
  * dwarf.c (prealloc_cu_tu_list): Always allocate at least one entry.

Fix an attempt to allocate an overlarge amount of memory when decoding a corrupt ELF format file.

  PR 30311
  * readelf.c (uncompress_section_contents): Check for a suspiciously large uncompressed size.

Fix illegal memory access when disassembling corrupt NFP binaries.

  PR 30310
  * nfp-dis.c (init_nfp6000_priv): Check that the output section exists.

gdb: fix indentation within print_one_breakpoint_location

Spotted some code in print_one_breakpoint_location that was not
indented correctly, this commit just changes the indentation.

There should be no user visible changes after this commit.

gdb/testsuite: fix typo gdb_name_name -> gdb_test_name

Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name
instead of $gdb_test_name in one place.  Fixed in this commit.

gdb: warn when converting h/w watchpoints to s/w

On amd64 (at least) if a user sets a watchpoint before the inferior
has started then GDB will assume that a hardware watchpoint can be
created.

When the inferior starts there is a chance that the watchpoint can't
actually be create as a hardware watchpoint, in which case (currently)
GDB will silently convert the watchpoint to a software watchpoint.
Here's an example session:

  (gdb) p sizeof var
  $1 = 4000
  (gdb) watch var
  Hardware watchpoint 1: var
  (gdb) info watchpoints
  Num     Type           Disp Enb Address    What
  1       hw watchpoint  keep y              var
  (gdb) starti
  Starting program: /home/andrew/tmp/watch

  Program stopped.
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) info watchpoints
  Num     Type           Disp Enb Address            What
  1       watchpoint     keep y                      var
  (gdb)

Notice that before the `starti` command the watchpoint is showing as a
hardware watchpoint, but afterwards it is showing as a software
watchpoint.  Additionally, note that we clearly told the user we
created a hardware watchpoint:

  (gdb) watch var
  Hardware watchpoint 1: var

I think this is bad.  I used `starti`, but if the user did `start` or
even `run` then the inferior is going to be _very_ slow, which will be
unexpected -- after all, we clearly told the user that we created a
hardware watchpoint, and the manual clearly says that hardware
watchpoints are fast (at least compared to s/w watchpoints).

In this patch I propose adding a new warning which will be emitted
when GDB downgrades a h/w watchpoint to s/w.  The session now looks
like this:

  (gdb) p sizeof var
  $1 = 4000
  (gdb) watch var
  Hardware watchpoint 1: var
  (gdb) info watchpoints
  Num     Type           Disp Enb Address    What
  1       hw watchpoint  keep y              var
  (gdb) starti
  Starting program: /home/andrew/tmp/watch
  warning: watchpoint 1 downgraded to software watchpoint

  Program stopped.
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) info watchpoints
  Num     Type           Disp Enb Address            What
  1       watchpoint     keep y                      var
  (gdb)

The important line is:

  warning: watchpoint 1 downgraded to software watchpoint

It's not much, but hopefully it will be enough to indicate to the user
that something unexpected has occurred, and hopefully, they will not
be surprised when the inferior runs much slower than they expected.

I've added an amd64 only test in gdb.arch/, I didn't want to try
adding this as a global test as other architectures might be able to
support the watchpoint request in h/w.

Also the test is skipped for extended-remote boards as there's a
different set of options for limiting hardware watchpoints on remote
targets, and this test isn't about them.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb/riscv: Support c.li in prologue unwinder

I was seeing some failures in gdb.threads/omp-par-scope.exp when run
on a riscv64 target.  It turns out the cause of the problem is that I
didn't have debug information installed for libgomp.so, which this
test makes use of.  The test requires GDB to backtrace through a
libgomp function, and the riscv prologue unwinder was failing to
unwind this particular stack frame.

The reason for the failure to unwind was that the function prologue
includes a c.li (compressed load immediate) instruction, and the riscv
prologue scanning unwinder doesn't know what to do with this
instruction, though the unwinder does understand c.lui (compressed
load unsigned immediate).

This commit adds support for c.li.  After this GDB is able to unwind
through libgomp, and I no longer see any unexpected failures in
gdb.threads/omp-par-scope.exp.

I've also included a new test in gdb.arch/ which specifically checks
for our c.li support.

Automatic date update in version.in

gdb/dwarf: Fix MinGW build

Unfortunately MinGW doesn't support std::future yet, so this causes the
build to fail.  Use GDB's version which provides a fallback for this case.

Tested for regressions on native aarch64-linux.

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

Handle unwinding from SEGV on Windows

PR win32/30255 points out that a call to a NULL function pointer will
leave gdb unable to "bt" on Windows.

I tracked this down to the amd64 windows unwinder.  If we treat this
scenario as if it were a leaf function, unwinding works fine.

I'm not completely sure this patch is the best way.  I considered
having it check for 'pc==0' -- but then I figured this could affect
any inaccessible PC, not just the special 0 value.

No test case because I can't run dejagnu tests on Windows.  I tested
this by hand using the test case in the bug.

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

x86: Add inval tests for AMX instructions

gas/ChangeLog:

* testsuite/gas/i386/i386.exp: Run AMX-FP16 and AMX-COMPLEX
inval testcases.
* testsuite/gas/i386/x86-64-amx-inval.l: Add AMX-BF16 tests.
* testsuite/gas/i386/x86-64-amx-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-complex-inval.l: New test.
* testsuite/gas/i386/x86-64-amx-complex-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-fp16-inval.l: Ditto.
* testsuite/gas/i386/x86-64-amx-fp16-inval.s: Ditto.

Automatic date update in version.in

Automatic date update in version.in

Fix typos in previous commit of gdb.texinfo.

* gdb/doc/gdb.texinfo (Requirements): Fix typos.

libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGS

This is a bug in the intersection of two obscure options that cannot
even be invoked from ld with a feature added to stop ld of the
same input file repeatedly from crashing the linker.

The latter fix involved tracking input files (internally to libctf) not
just with their input CU name but with a version of their input CU name
that was augmented with a numeric prefix if their linker input file name
was changed, to prevent distinct CTF dicts with the same cuname from
overwriting each other. (We can't use just the linker input file name
because one linker input can contain many CU dicts, particularly under
ld -r).  If these inputs then produced conflicting types, those types
were emitted into similarly-named output dicts, so we needed similar
machinery to detect clashing output dicts and add a numeric prefix to
them as well.

This works fine, except that if you used the cu-mapping feature to force
double-linking of CTF (so that your CTF can be grouped into output dicts
larger than a single translation unit) and then also used
CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the
mapping to be created (even if empty), we did the creation of empty dicts
first, and then all the actual content got considered to be a clash. So
you ended up with a pile of useless empty dicts and then all the content
was in full dicts with the same names suffixed with a #0.  This seems
likely to confuse consumers that use this facility.

Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking
is complete, not before it runs.

No impact on ld, which does not do cu-mapped links or pass
CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link().

libctf/
* ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one
        already exists and we are making one for no input in particular.
        (ctf_link): Emit empty CTF dicts corresponding to no input in
        particular only after linkiing is complete.

libctf: propagate errors from parents correctly

CTF dicts have per-dict errno values: as with other errno values these
are set on error and left unchanged on success.  This means that all
errors *must* set the CTF errno: if a call leaves it unchanged, the
caller is apt to find a previous, lingering error and misinterpret
it as the real error.

There are many places in libctf where we carry out operations on parent
dicts as a result of carrying out other user-requested operations on
child dicts (e.g. looking up information on a pointer to a type will
look up the type as well: the pointer might well be in a child and the
type it's a pointer to in the parent).  Those operations on the parent
might fail; if they do, the error must be correctly reflected on the
child that the user-visible operation was carried out on.  In many
places this was not happening.

So, audit and fix all those places.  Add tests for as many of those
cases as possible so they don't regress.

libctf/
* ctf-create.c (ctf_add_slice): Use the original dict.
* ctf-lookup.c (ctf_lookup_variable): Propagate errors.
(ctf_lookup_symbol_idx): Likewise.
* ctf-types.c (ctf_member_next): Likewise.
(ctf_type_resolve_unsliced): Likewise.
(ctf_type_aname): Likewise.
(ctf_member_info): Likewise.
(ctf_type_rvisit): Likewise.
(ctf_func_type_info): Set the error on the right dict.
(ctf_type_encoding): Use the original dict.
* testsuite/libctf-writable/error-propagation.*: New test.

libctf, tests: do not assume host and target have identical field offsets

The newly-introduced libctf-lookup unnamed-field-info test checks
C compiler-observed field offsets against libctf-computed ones
by #including the testcase in the lookup runner as well as
generating CTF for it.  This only works if the host, on which
the lookup runner is compiled and executed, is the same architecture as
the target, for which the CTF is generated: when crossing, the trick
may fail.

So pass down an indication of whether this is a cross into the
testsuite, and add a new no_cross flag to .lk files that is used to
suppress test execution when a cross-compiler is being tested.

libctf/
* Makefile.am (check_DEJAGNU): Pass down TEST_CROSS.
* Makefile.in: Regenerated.
* testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to
implement the new no_cross option.
* testsuite/libctf-lookup/unnamed-field-info.lk: Mark as
no_cross.

Automatic date update in version.in

Rewrite Ada symbol cache

In an experiment I'm trying, I needed Ada symbol cache entries to be
allocated with 'new'.  This patch reimplements the symbol cache to use
the libiberty hash table and to use new and delete.  A couple of other
minor cleanups are done.