[aarch64] Fix removal of non-address bits for PAuth

PR gdb/28947

The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant.  This
constant represents the number of address bits in a pointer.

Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.

But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information.  We could also have
cases where we're using both PAuth and MTE.

We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.

This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses.  But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.

The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits.  The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.

While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.

Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947

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

gas: restore Dwarf info generation after macro diagnostic adjustments

While 6fdb723799e2 ("gas: re-work line number tracking for macros and
their expansions") was meant to leave generated Dwarf as is, it really
didn't (and the testcase intended to catch that wasn't covering the case
which broke). Its adjustment to buffer_and_nest() didn't go far enough,
leading to the "linefile" directive inserted at the top to also be
processed later in the PR gas/16908 workaround (which clearly isn't
intended - it's being put there for processing during macro expansion
only). That unnoticed flaw in turn led me to work around it by a
(suspicious to me already at the time) conditional in as_where().

x86: change representation of extension opcode

Having a "None" field in the vast majority of entries is needlessly
cluttering the overall table. Instead of this being a separate field,
use a representation matching that of Intel SDM and AMD PM for the main
use of the field: Append the value after a / as the separator.

gdbsupport: change xml_escape_text_append's parameter from pointer to reference

The passed in string can't be nullptr, it makes more sense to pass in a
reference.

Change-Id: Idc8bd38abe1d6d9b44aa227d7856956848c233b3

gdb: remove static buffer in command_line_input

[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]

The use of the static buffer in command_line_input is becoming
problematic, as explained here [1].  In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input.  The command line is stored in
command_line_input's static buffer.  Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer.  After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered.  For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free.  Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.

Fix that by removing the static buffer.  I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution.  The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization.  I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content.  It fills the buffer and returns a
pointers to the C string inside.  The callees that don't need to return
dynamically-allocated content simply don't use it.

So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.

One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`.  I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.

A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:

  /* We have a complete command line now.  Prepare for the next
     command, but leave ownership of memory to the buffer .  */
  cmd_line_buffer->used_size = 0;

I think the new way is clearer.

[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/

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

Automatic date update in version.in

libsframe asan: avoid generating misaligned loads

There are two places where unaligned loads were seen on aarch64:
  - #1. access to the SFrame FRE stack offsets in the in-memory
    representation/abstraction provided by libsframe.
  - #2. access to the SFrame FRE start address in the on-disk representation
    of the frame row entry.

For #1, we can fix this by reordering the struct members of
sframe_frame_row_entry in libsframe/sframe-api.h.

For #2, we need to default to using memcpy instead, and copy out the bytes
to a location for output.

SFrame format is an unaligned on-disk format. As such, there are other blobs
of memory in the on-disk SFrame FRE that are on not on their natural
boundaries.  But that does not pose further problems yet, because the users
are provided access to the on-disk SFrame FRE data via libsframe's
sframe_frame_row_entry, the latter has its' struct members aligned on their
respective natural boundaries (and initialized using memcpy).

PR 29856 libsframe asan: load misaligned at sframe.c:516

ChangeLog:

PR libsframe/29856
* bfd/elf64-x86-64.c: Adjust as the struct members have been
reordered.
* libsframe/sframe.c (sframe_decode_fre_start_address): Use
memcpy to perform 16-bit/32-bit reads.
* libsframe/testsuite/libsframe.encode/encode-1.c: Adjust as the
struct members have been reordered.

include/ChangeLog:

PR libsframe/29856
* sframe-api.h: Reorder fre_offsets for natural alignment.

gdb/testsuite: don't delete command files in gdb.base/commands.exp

Don't delete the runtime-generated command files.  This makes it easier
to reproduce tests by hand.

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

Move streq and compare_cstrings to gdbsupport

It seems to me that streq and compare_cstrings belong near the other
string utility functions in common-utils.h; and furthermore that streq
ought to be inlined.  This patch makes this change.

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

Remove subset_compare

I stumbled across subset_compare today, and after looking at the
callers I realized it could be removed and replaced with calls to
startswith.

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

gdb: use gdb_assert not internal_error

Spotted a couple of places in findvar.c where we use:

  if ( ! CONDITION )
    internal_error ("...");

this commit changes these to be:

  gdb_assert ( CONDITION );

which I think is better.

Unless we happen to hit the internal_error calls (which was bad) there
should be no user visible changes after this commit.

gdb: some int to bool conversion in remote-sim.c

Some obvious int to bool conversion in remote-sim.c, there should be
no user visible changes after this commit.

gdb: make more use of make_target_connection_string

I noticed that we have a function make_target_connection_string which
wraps all the logic for creating a string that describes a target
connection - but in some places we are not calling this function,
instead we duplicate the function's logic.

This commit cleans this up, and calls make_target_connection_string
where possible.

There should be no user visible changes after this commit.

gdb: int to bool conversion in tracefile.c

Some obvious int to bool conversion in tracefile.c.

Should be no user visible changes after this commit.

[gdb/testsuite] Fix gdb.base/condbreak-multi-context.exp with gcc 4.8.5

With gcc 4.8.5, I run into:
...
Running gdb.base/condbreak-multi-context.exp ...
gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
  data member initializers only available with -std=c++11 or -std=gnu++11 \
  [enabled by default]
   int b = 20;
           ^
...

Fix this by making it a static const.

Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.

Automatic date update in version.in

gdb/maint: add core file name to 'maint info program-spaces' output

Each program space can have an associated core file.  Include this
information in the output of 'maint info program-spaces'.

gdb: ensure all targets are popped before an inferior is destructed

Now that the inferiors target_stack automatically manages target
reference counts, we might think that we don't need to unpush targets
when an inferior is deleted...

...unfortunately that is not the case.  The inferior::unpush function
can do some work depending on the type of target, so it is important
that we still pass through this function.

To ensure that this is the case, in this commit I've added an assert
to inferior::~inferior that ensures the inferior's target_stack is
empty (except for the ever present dummy_target).

I've then added a pop_all_targets call to delete_inferior, otherwise
the new assert will fire in, e.g. the gdb.python/py-inferior.exp test.

gdb: remove the pop_all_targets (and friends) global functions

This commit removes the global functions pop_all_targets,
pop_all_targets_above, and pop_all_targets_at_and_above, and makes
them methods on the inferior class.

As the pop_all_targets functions will unpush each target, which
decrements the targets reference count, it is possible that the target
might be closed.

Right now, closing a target, in some cases, depends on the current
inferior being set correctly, that is, to the inferior from which the
target was popped.

To facilitate this I have used switch_to_inferior_no_thread within the
new methods.  Previously it was the responsibility of the caller to
ensure that the correct inferior was selected.

In a couple of places (event-top.c and top.c) I have been able to
remove a previous switch_to_inferior_no_thread call.

In remote_unpush_target (remote.c) I have left the
switch_to_inferior_no_thread call as it is required for the
generic_mourn_inferior call.

gdb: remove decref_target

The decref_target function is not really needed.  Calling
target_ops::decref will just redirect to decref_target anyway, so why
not just rename decref_target to target_ops::decref?

That's what this commit does.

It's not exactly renaming to target_ops::decref, because the decref
functionality is handled by a policy class, so the new name is now
target_ops_ref_policy::decref.

There should be no user visible change after this commit.

gdb: have target_stack automate reference count handling

This commit changes the target_stack class from using a C style array
of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>.  The
benefit of this change is that some of the reference counting of
target_ops objects is now done automatically.

This commit fixes a crash in gdb.python/py-inferior.exp where GDB
crashes at exit, leaving a core file behind.

The crash occurs in connpy_connection_dealloc, and is actually
triggered by this assert:

gdb_assert (conn_obj->target == nullptr);

Now a little aside...

    ... the assert is never actually printed, instead GDB crashes due
    to calling a pure virtual function.  The backtrace at the point of
    crash looks like this:

      #7  0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
      #8  0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
      #9  0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
      #10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
      #11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
      #12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
      #13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
      #14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>

    Notice in frame #12 we called target_ops::supports_terminal_ours,
    however, this is the_dummy_target, which is of type dummy_target,
    and so we should have called dummy_target::supports_terminal_ours.
    I believe the reason we ended up in the wrong implementation of
    supports_terminal_ours (which is a virtual function) is because we
    made the call during GDB's shut-down, and, I suspect, the vtables
    were in a weird state.

    Anyway, the point of this patch is not to fix GDB's ability to
    print an assert during exit, but to address the root cause of the
    assert.  With that aside out of the way, we can return to the main
    story...

Connections are represented in Python with gdb.TargetConnection
objects (or its sub-classes).  The assert in question confirms that
when a gdb.TargetConnection is deallocated, the underlying GDB
connection has itself been removed from GDB.  If this is not true then
we risk creating multiple different gdb.TargetConnection objects for
the same connection, which would be bad.

To ensure that we have one gdb.TargetConnection object for each
connection, the all_connection_objects map exists, this maps the
process_stratum_target object (the connection) to the
gdb.TargetConnection object that represents the connection.

When a connection is removed in GDB the connection_removed observer
fires, which we catch with connpy_connection_removed, this function
then sets conn_obj->target to nullptr, and removes the corresponding
entry from the all_connection_objects map.

The first issue here is that connpy_connection_dealloc is being called
as part of GDB's exit code, which is run after the Python interpreter
has been shut down.  The connpy_connection_dealloc function is used to
deallocate the gdb.TargetConnection Python object.  Surely it is
wrong for us to be deallocating Python objects after the interpreter
has been shut down.

The reason why connpy_connection_dealloc is called during GDB's exit
is that the global all_connection_objects map is still holding a
reference to the gdb.TargetConnection object.  When the map is
destroyed during GDB's exit, the gdb.TargetConnection objects within
the map can finally be deallocated.

The reason why all_connection_objects has contents when GDB exits, and
the reason the assert fires, is that, when GDB exits, there are still
some connections that have not yet been removed from GDB, that is,
they have a non-zero reference count.

If we take a look at quit_force (top.c) you can see that, for each
inferior, we call pop_all_targets before we (later in the function)
call do_final_cleanups.  It is the do_final_cleanups call that is
responsible for shutting down the Python interpreter.  The
pop_all_targets calls should, in theory, cause all the connections to
be removed from GDB.

That this isn't working indicates that some targets have a non-zero
reference count even after this final pop_all_targets call, and
indeed, when I debug GDB, that is what I see.

I tracked the problem down to delete_inferior where we do some house
keeping, and then delete the inferior object, which calls
inferior::~inferior.

In neither delete_inferior or inferior::~inferior do we call
pop_all_targets, and it is this missing call that means we leak some
references to the target_ops objects on the inferior's target_stack.

In this commit I will provide a partial fix for the problem.  I say
partial fix, but this will actually be enough to resolve the crash.
In a later commit I will provide the final part of the fix.

As mentioned at the start of the commit message, this commit changes
the m_stack in target_stack to hold target_ops_ref objects.  This
means that when inferior::~inferior is called, and m_stack is
released, we automatically decrement the target_ops reference count.
With this change in place we no longer leak any references, and now,
in quit_force the final pop_all_targets calls will release the final
references.  This means that the targets will be correctly closed at
this point, which means the connections will be removed from GDB and
the Python objects deallocated before the Python interpreter shuts
down.

There's a slight oddity in target_stack::unpush, where we std::move
the reference out of m_stack like this:

  auto ref = std::move (m_stack[stratum]);

the `ref' isn't used explicitly, but it serves to hold the
target_ops_ref until the end of the scope while allowing the m_stack
entry to be reset back to nullptr.  The alternative would be to
directly set the m_stack entry to nullptr, like this:

  m_stack[stratum] = nullptr;

The problem here is that when we set the m_stack entry to nullptr we
first decrement the target_ops reference count, and then set the array
entry to nullptr.

If the decrement means that the target_ops object reaches a zero
reference count then the target_ops object will be closed by calling
target_close.  In target_close we ensure that the target being closed
is not in any inferiors target_stack.

As we decrement before clearing, then this check in target_close will
fail, and an assert will trigger.

By using std::move to move the reference out of m_stack, this clears
the m_stack entry, meaning the inferior no longer contains the
target_ops in its target_stack.  Now when the REF object goes out of
scope and the reference count is decremented, target_close can run
successfully.

I've made use of the Python connection_removed listener API to add a
test for this issue.  The test installs a listener and then causes
delete_inferior to be called, we can then see that the connection is
then correctly removed (because the listener triggers).

gdb/remote: remove some manual reference count handling

While working on some other target_ops reference count related code, I
spotted that in remote.c we do some manual reference count handling,
i.e. we call target_ops::incref and decref_target (which wraps
target_ops::decref).

I think it would be better to make use of gdb::ref_ptr to automate the
reference count management.

So, this commit updates scoped_mark_target_starting in two ways,
first, I use gdb::ref_ptr to handle the reference counts.  Then,
instead of using the scoped_mark_target_starting constructor and
destructor to set and reset the starting_up flag, I now use a
scoped_restore_tmpl object to set and restore the flag.

The above changes mean that the scoped_mark_target_starting destructor
can be completely removed, and the constructor body is now empty.

I've also fixed a typo in the class comment.

The only change in behaviour after this commit is that previously we
didn't care what the value of starting_up was, we just set it to true
in the constructor and false in the destructor.

Now, I assert that the flag is initially false, then set the flag true
when the scoped_mark_target_starting is created.

As the starting_up flag is initialized to false then, for the assert
to fire, we would need to recursively enter
remote_target::start_remote_1, which I don't think is something we
should be doing, so I think the new assert is an improvement.

Re: ld, gold: remove support for -z bndplt (MPX prefix)

Don't attempt to run gold tests with -z bndplt

* testsuite/Makefile.am (exception_x86_64_bnd_test, bnd_plt_1.sh),
(bnd_ifunc_1.sh, bnd_ifunc_2.sh): Delete rules.
* testsuite/Makefile.in: Regenerate.
* testsuite/bnd_ifunc_1.s: Delete.
* testsuite/bnd_ifunc_1.sh: Delete.
* testsuite/bnd_ifunc_2.s: Delete.
* testsuite/bnd_ifunc_2.sh: Delete.
* testsuite/bnd_plt_1.s: Delete.
* testsuite/bnd_plt_1.sh: Delete.

asan: buffer overflow in sh_reloc

* coff-sh.c (sh_reloc): Use bfd_reloc_offset_in_range.

Fix haiku ld dependencies

I noticed after commit 8ad93045ed, "ld, gold: remove support for -z
bndplt (MPX prefix)", that some of my builds were failing with

eelf_x86_64_haiku.c:650:9: error: no member named 'bndplt' in 'struct elf_linker_x86_params'
        params.bndplt = true;
        ~~~~~~ ^

* emulparams/aarch64haiku.sh: Use "source_sh" rather than ".".
* emulparams/armelf_haiku.sh: Likewise.
* emulparams/elf32ppchaiku.sh: Likewise.
* emulparams/elf_mipsel_haiku.sh: Likewise.
* emulparams/elf_x86_64_haiku.sh: Likewise.

gdb: add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT

After the previous commit converted symbol-lookup debug to use the new
debug scheme, this commit adds SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT.

The previous commit didn't add SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT
because symbol-lookup debug is controlled by an 'unsigned int' rather
than a 'bool' control variable, we use the numeric value to offer
different levels of verbosity for symbol-lookup debug.

The *_SCOPED_DEBUG_ENTER_EXIT mechanism currently relies on capturing
a reference to the bool control variable, and evaluating the variable
both on entry, and at exit, this is done in the scoped_debug_start_end
class (see gdbsupport/common-debug.h).

This commit templates scoped_debug_start_end so that the class can
accept either a 'bool &' or an invokable object, e.g. a lambda
function, or a function pointer.

The existing scoped_debug_start_end and scoped_debug_enter_exit macros
in common-debug.h are updated to support scoped_debug_enter_exit being
templated, however, nothing outside of common-debug.h needs to change.

I've then added SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT in symtab.h, and
added a couple of token uses in symtab.c.  I didn't want to add too
much in this first commit, this is really about updating
common-debug.h to support this new functionality.

Within symtab.h I created a couple of global functions that can be
used to query the status of the symbol_lookup_debug control variable,
these functions are then used within the two existing macros:

  symbol_lookup_debug_printf
  symbol_lookup_debug_printf_v

and also in the new SYMBOL_LOOKUP_SCOPED_DEBUG_ENTER_EXIT macro.

gdb: convert 'set debug symbol-lookup' to new debug printing scheme

Convert the implementation of 'set debug symbol-lookup' to the new
debug printing scheme.

In a few places I've updated the debug output to remove places where
the printed debug message included the function name, the new debug
scheme already adds that, but I haven't done all the possible updates.

gdb/testsuite: new test for recent dwarf reader issue

This commit provides a test for this commit:

  commit 55fc1623f942fba10362cb199f9356d75ca5835b
  Date:   Thu Nov 3 13:49:17 2022 -0600

      Add name canonicalization for C

Which resolves PR gdb/29105.  My reason for writing this test was a
desire to better understand the above commit, my process was to study
the commit until I thought I understood it, then write a test to
expose the issue.  As the original commit didn't have a test, I
thought it wouldn't hurt to commit this upstream.

The problem tested for here is already described in the above commit,
but I'll give a brief description here.  This description describes
GDB prior to the above commit:

  - Builtin types are added to GDB using their canonical name,
    e.g. "short", not "signed short",

  - When the user does something like 'p sizeof(short)', then this is
    handled in c-exp.y, and results in a call to lookup_signed_type
    for the name "int".  The "int" here is actually being looked up as
    the type for the result of the 'sizeof' expression,

  - In lookup_signed_type GDB first adds a 'signed' and looks for that
    type, so in this case 'signed int', and, if that lookup fails, GDB
    then looks up 'int',

  - The problem is that 'signed int' is not the canonical name for a
    signed int, so no builtin type with that name will be found, GDB
    will then go to each object file in turn looking for a matching
    type,

  - When checking each object file, GDB will first check the partial
    symtab to see if the full symtab should be expanded or not.
    Remember, at this point GDB is looking for 'signed int', there
    will be no partial symbols with that name, so GDB will not expand
    anything,

  - However, GDB checks each partial symbol using multiple languages,
    not just the current language (C in this case), so, when GDB
    checks using the C++ language, the symbol name is first
    canonicalized (the code that does this can be found
    lookup_name_info::language_lookup_name).  As the canonical form of
    'signed int' is just 'int', GDB then looks for any symbols with
    the name 'int', most partial symtabs will contain such a symbol,
    so GDB ends up expanding pretty much every symtab.

The above commit fixes this by avoiding the use of non-canonical names
with C, now the initial builtin type lookup will succeed, and GDB
never even considers whether to expand any additional symtabs.

The test case creates a library that includes char, short, int, and
long types, and a test program that links against the library.

In the test script we start the inferior, but don't allow it to
progress far enough that the debug information for the library has
been fully expanded yet.

Then we evaluate some 'sizeof(TYPE)' expressions.

In the buggy version of GDB this would cause the debug information
for the library to be fully expanded, while in the fixed version of
GDB this will not be the case.

We use 'info sources' to determine if the debug information has been
fully expanded or not.

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

gdb/testsuite: fix readnow detection

The following commit broke the readnow detection in the testsuite:

  commit dfaa040b440084dd73ebd359326752d5f44fc02c
  Date:   Mon Mar 29 18:31:31 2021 -0600

      Remove some "OBJF_READNOW" code from dwarf2_debug_names_index

The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output.  This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).

The following tests all currently depend on this detection:

  gdb.base/maint.exp
  gdb.cp/nsalias.exp
  gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
  gdb.dwarf2/dw2-stack-boundary.exp
  gdb.dwarf2/dw2-zero-range.exp
  gdb.dwarf2/gdb-index-nodebug.exp
  gdb.mi/mi-info-sources.exp
  gdb.python/py-symbol.exp
  gdb.rust/traits.exp

The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:

  gdb.opt/break-on-_exit.exp

The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).

When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.

Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check.  At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.

For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.

Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.

With these changes, all of the tests listed above now pass correctly
when using the readnow board.

RISC-V: Add string length check for operands in AS

The current AS accepts invalid operands due to miss of operands length check.
For example, "e6" is an invalid operand in (vsetvli a0, a1, e6, mf8, tu, ma),
but it's still accepted by assembler.  In detail, the condition check "strncmp
(array[i], *s, len) == 0" in arg_lookup function passes with "strncmp ("e64",
"e6", 2)" in the case above.  So the generated encoding is same as that of
(vsetvli a0, a1, e64, mf8, tu, ma).

This patch fixes issue above by prompting an error in such case and also adds
a new testcase.

gas/ChangeLog:

        * config/tc-riscv.c (arg_lookup): Add string length check for operands.
        * testsuite/gas/riscv/vector-insns-fail-vsew.d: New testcase for an illegal vsew.
        * testsuite/gas/riscv/vector-insns-fail-vsew.l: Likewise.
        * testsuite/gas/riscv/vector-insns-fail-vsew.s: Likewise.

x86: adjust type checking constructs

As Alan points out, ASAN takes issue with these constructs, for
current_templates being NULL. Wrap them in sizeof(), so the expressions
aren't actually evaluated.

ld, gold: remove support for -z bndplt (MPX prefix)

bfd/ChangeLog:

* elf-linker-x86.h (struct elf_linker_x86_params): Remove
bndplt.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Ignore
        R_X86_64_PLT32_BND.
(elf_x86_64_relocate_section): Similarly here.
(elf_x86_64_link_setup_gnu_properties): Ignore bndplt.
* elfxx-x86.c: Likewise.
* elfxx-x86.h: Likewise.

gold/ChangeLog:

* NEWS: Document -z bndplt.
* options.h (class General_options): Remove bndplt option.
* x86_64.cc (class Output_data_plt_x86_64_bnd): Remove.
(Target_x86_64::do_make_data_plt): Do not use
Output_data_plt_x86_64_bnd.
(Target_x86_64::Scan::get_reference_flags): Likewise.
(Target_x86_64::Scan::check_non_pic): Likewise.
(Target_x86_64::Scan::local): Likewise.
(Target_x86_64::Scan::global): Likewise.

ld/ChangeLog:

* NEWS: Document -z bndplt.
* emulparams/elf_x86_64.sh: Remove bndplt option.
* ld.texi: Likewise.
* testsuite/ld-x86-64/x86-64.exp:
* testsuite/ld-x86-64/bnd-branch-1-now.d: Removed.
* testsuite/ld-x86-64/bnd-branch-1.d: Removed.
* testsuite/ld-x86-64/bnd-branch-1.s: Removed.
* testsuite/ld-x86-64/bnd-ifunc-1-now.d: Removed.
* testsuite/ld-x86-64/bnd-ifunc-1.d: Removed.
* testsuite/ld-x86-64/bnd-ifunc-1.s: Removed.
* testsuite/ld-x86-64/bnd-ifunc-2-now.d: Removed.
* testsuite/ld-x86-64/bnd-ifunc-2.d: Removed.
* testsuite/ld-x86-64/bnd-ifunc-2.s: Removed.
* testsuite/ld-x86-64/bnd-plt-1-now.d: Removed.
* testsuite/ld-x86-64/bnd-plt-1.d: Removed.
* testsuite/ld-x86-64/mpx.exp: Removed.
* testsuite/ld-x86-64/mpx1.out: Removed.
* testsuite/ld-x86-64/mpx1a.c: Removed.
* testsuite/ld-x86-64/mpx1a.rd: Removed.
* testsuite/ld-x86-64/mpx1b.c: Removed.
* testsuite/ld-x86-64/mpx1c.c: Removed.
* testsuite/ld-x86-64/mpx1c.rd: Removed.
* testsuite/ld-x86-64/mpx2.out: Removed.
* testsuite/ld-x86-64/mpx2a.c: Removed.
* testsuite/ld-x86-64/mpx2a.rd: Removed.
* testsuite/ld-x86-64/mpx2b.c: Removed.
* testsuite/ld-x86-64/mpx2c.c: Removed.
* testsuite/ld-x86-64/mpx2c.rd: Removed.
* testsuite/ld-x86-64/mpx3.dd: Removed.
* testsuite/ld-x86-64/mpx3a.s: Removed.
* testsuite/ld-x86-64/mpx3b.s: Removed.
* testsuite/ld-x86-64/mpx3n.dd: Removed.
* testsuite/ld-x86-64/mpx4.dd: Removed.
* testsuite/ld-x86-64/mpx4a.s: Removed.
* testsuite/ld-x86-64/mpx4b.s: Removed.
* testsuite/ld-x86-64/mpx4n.dd: Removed.
* testsuite/ld-x86-64/pr20800a.S: Removed.
* testsuite/ld-x86-64/pr20800b.S: Removed.
* testsuite/ld-x86-64/pr21038a-now.d: Removed.
* testsuite/ld-x86-64/pr21038a.d: Removed.
* testsuite/ld-x86-64/pr21038a.s: Removed.
* testsuite/ld-x86-64/pr21038b-now.d: Removed.
* testsuite/ld-x86-64/pr21038b.d: Removed.
* testsuite/ld-x86-64/pr21038b.s: Removed.
* testsuite/ld-x86-64/pr21038c-now.d: Removed.
* testsuite/ld-x86-64/pr21038c.d: Removed.
* testsuite/ld-x86-64/pr21038c.s: Removed.

asan: signed integer overflow in display_debug_frames

* dwarf.c (struct Frame_Chunk): Make col_offset an int64_t.
Adjust all places allocating col_offset and col_type to use
the size of the array element rather than the size of a type.
(frame_display_row): Adjust printing of col_offset.
(display_debug_frames): Factor out multiplication by
code_factor and data_factor.  Avoid signed overflow.  Use
64-bit variables.

Don't access freed memory printing objcopy warning

abfd->filename will be freed if bfd_close gets far enough to delete
the bfd.  It's possible to have an error from fclose at this point.

* objcopy.c (copy_archive): Dup filename before closing bfd for
potential use in bfd_nonfatal_message.

Automatic date update in version.in

Fix control-c handling on Windows

As Hannes pointed out, the Windows target-async patches broke C-c
handling there.  Looking into this, I found a few oddities, fixed
here.

First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent.
I think this event can be ignored by the inferior, so it's not a great
way to interrupt.  Instead, using DebugBreakProcess (or a more
complicated thing for Wow64) seems better.

Second, windows_nat_target did not implement the pass_ctrlc method.
Implementing this lets us remove the special code to call
SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c
handling.  I believe that this should also fix the race that's
described in the comment that's being removed.

Initially, I thought a simpler version of this patch would work.
However, I think what happens is that some other library (I'm not sure
what) calls SetConsoleCtrlHandler while gdb is running, and this
intercepts and handles C-c -- so that the gdb SIGINT handler is not
called.  C-break continues to work, presumably because whatever
handler is installed ignores it.

This patch works around this issue by ensuring that the gdb handler
always comes first.

Refactor code to check for terminal sharing

This refactors the code to check for terminal sharing.
is_gdb_terminal is exported, and sharing_input_terminal_1 is renamed,
slightly refactored, and moved to posix-hdep.c.  A new
Windows-specific implementation of this function is added to
mingw-hdep.c.

MSDN has a warning about GetConsoleProcessList

    This API is not recommended and does not have a virtual terminal
    equivalent. [...] Applications remoting via cross-platform
    utilities and transports like SSH may not work as expected if
    using this API.

However, we believe this isn't likely to be an issue for gdb.

Use gdb::optional for sigint_ours

sigint_ours (and sigquit_ours) can be used without being set.  Avoid
this problem by changing them to gdb::optional and checking that they
are in fact set before using the value.

Rename install_sigint_handler

A subsequent patch will introduce a global 'install_sigint_handler'
function, so first rename the static one in extension.c.

[gdb/tdep] Fix s390_linux_nat_target::stopped_by_watchpoint

On s390x-linux, I run into:
...
(gdb) continue^M
Continuing.^M
breakpoint.c:5784: internal-error: bpstat_stop_status_nowatch: \
  Assertion `!target_stopped_by_watchpoint ()' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
FAIL: gdb.threads/watchpoint-fork.exp: parent: singlethreaded: \
  breakpoint after the first fork (GDB internal error)
...

What happens is the follow:
- a watchpoint event triggers
- the event is processed, s390_linux_nat_target::stopped_by_watchpoint is called and
  it returns true, as expected
- the watchpoint event is reported by gdb, and gdb stops
- we issue a continue command
- a fork event triggers
- the event is processed, and during processing that event
  s390_linux_nat_target::stopped_by_watchpoint is called again, and returns
  true
- the assertion fails, because the function is expected to return false

The function s390_linux_nat_target::stopped_by_watchpoint returns true the
second time, because it looks at the exact same data that was looked at when
it was called the first time, and that data hasn't changed.

There's code in the same function that intends to prevent that from happening:
...
      /* Do not report this watchpoint again.  */
      memset (&per_lowcore, 0, sizeof (per_lowcore));
      if (ptrace (PTRACE_POKEUSR_AREA, s390_inferior_tid (), &parea, 0) < 0)
       perror_with_name (_("Couldn't clear watchpoint status"));
...
and that probably used to work for older kernels, but no longer does since
linux kernel commit 5e9a26928f55 ("[S390] ptrace cleanup").

Fix this by copying this:
...
  siginfo_t siginfo;
  if (!linux_nat_get_siginfo (inferior_ptid, &siginfo))
    return false;
  if (siginfo.si_signo != SIGTRAP
      || (siginfo.si_code & 0xffff) != TRAP_HWBKPT)
    return false;
...
from aarch64_linux_nat_target::stopped_data_address and remove the
obsolete watchpoint status clearing code.

Tested on s390x-linux.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>

gold: Remove BND from 64-bit x86-64 IBT PLT

Since MPX support has been removed from x86-64 psABI, remove BND from
64-bit IBT PLT by using 32-bit IBT PLT.

PR gold/29851
* x86_64.cc (Output_data_plt_x86_64_ibt<32>::first_plt_entry):
Renamed to ...
(Output_data_plt_x86_64_ibt<size>::first_plt_entry): This.
(Output_data_plt_x86_64_ibt<64>::first_plt_entry): Removed.
(Output_data_plt_x86_64_ibt<size>::do_fill_first_plt_entry):
Drop the size == 32 check.
(Output_data_plt_x86_64_ibt<32>::plt_entry): Renamed to ...
(Output_data_plt_x86_64_ibt<size>::plt_entry): This.
(Output_data_plt_x86_64_ibt<64>::plt_entry): Removed.
(Output_data_plt_x86_64_ibt<32>::aplt_entry): Renamed to ...
(Output_data_plt_x86_64_ibt<size>::aplt_entry): This.
(Output_data_plt_x86_64_ibt<64>::aplt_entry): Removed.
(Output_data_plt_x86_64_ibt<size>::do_fill_plt_entry): Drop the
size == 32 check.
(Output_data_plt_x86_64_ibt<size>::fill_aplt_entry): Likewise.

Remove two unnecessary casts

A couple of calls to parse_probe_linespec had an unnecessary cast.  I
suspect this cast was never needed, but once commands were changed to
take a 'const' argument, they became completely obsolete.  Tested by
rebuilding.

gdb/testsuite: avoid creating temp file in gdb/testsuite/ directory

After this commit:

  commit 33c1395cf5e9deec7733691ba32c450e5c27f757
  Date:   Fri Nov 11 15:26:46 2022 +0000

      gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang

The gdb.trace/unavailable-dwarf-piece.exp test script was creating a
temporary file in the build/gdb/testsuite/ directory, instead of in
the expected place in the outputs directory.

Fix this by adding a call to standard_output_file.

[gdb/testsuite] Fix gdb.python/py-disasm.exp on s390x

On s390x-linux, I run into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
   0x0000000001000638 <+0>:     stg     %r11,88(%r15)^M
   0x000000000100063e <+6>:     lgr     %r11,%r15^M
   0x0000000001000642 <+10>:    nop     0^M
=> 0x0000000001000646 <+14>:    nop     0^M
   0x000000000100064a <+18>:    nop     0^M
   0x000000000100064e <+22>:    lhi     %r1,0^M
   0x0000000001000652 <+26>:    lgfr    %r1,%r1^M
   0x0000000001000656 <+30>:    lgr     %r2,%r1^M
   0x000000000100065a <+34>:    lg      %r11,88(%r11)^M
   0x0000000001000660 <+40>:    br      %r14^M
End of assembler dump.^M
(gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
...

The problem is that the test-case expects "nop" but on s390x we have instead
"nop\t0".

Fix this by allowing the insn.

Tested on s390x-linux and x86_64-linux.

gas: re-work line number tracking for macros and their expansions

The PR gas/16908 workaround aimed at uniformly reporting line numbers
to reference macro invocation sites. As mentioned in a comment this may
be desirable for small macros, but often isn't for larger ones. As a
first step improve diagnostics to report both locations, while aiming at
leaving generated debug info unaltered.

Note that macro invocation context is lost for any diagnostics issued
only after all input was processed (or more generally for any use of
as_*_where(), as the functions can't know whether the passed in location
is related to [part of] the present stack of locations). To maintain the
intended workaround behavior for PR gas/16908, a new as_where() is
introduced to "look through" macro invocations, while the existing
as_where() is renamed (and used in only very few places for now). Down
the road as_where() will likely want to return a list of (file,line)
pairs.

Arm: avoid unhelpful uses of .macro in testsuite

Macros with just a single use site are a little pointless to have, and
even in further cases .irp is more suitable for the purpose. Expand such
inline, avoiding the need to touch the testcases when diagnostics are
changed for code resulting from macro expansion.

While there also make what was "iter_mla" in sp-usage-thumb2-relax cover
smlatt as well, rather than testing smlabt twice.

Fix crash in is_nocall_function

is_nocall_function anticipates only being called for a function or a
method.  However, PR gdb/29871 points out a situation where an unusual
expression -- but one that parses to a valid, if extremely weird,
function call -- breaks this assumption.

This patch changes is_nocall_function to remove this assert and
instead simply return 'false' in this case.

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

Replace gdbpy_should_stop with gdbpy_breakpoint_cond_says_stop

In 2014, the function `gdbpy_should_stop' has been replaced with
`gdbpy_breakpoint_cond_says_stop'

This replaces `gdbpy_should_stop' with `gdbpy_breakpoint_cond_says_stop' in the
comments.

Since `gdbpy_should_stop' has been renamed as noted in `gdb/ChangeLog-2014':

* python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
from gdbpy_should_stop.  Change result type to enum scr_bp_stop.

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

asan: mips_hi16_list segfault in bfd_get_section_limit_octets

static variables like mips_hi16_list are nasty for applications using
bfd.  It is possible when opening and closing bfds with mis-matched
hi/lo relocs to leave a stale section pointer on the list.  That can
cause a segfault if multiple bfds are being processed.

Tidying the list when closing is sufficient to stop this happening
(and fixes small memory leaks).  This patch goes further and moves
mips_hi16_list to where it belongs in the bfd tdata.

* elf32-mips.c (bfd_elf32_close_and_cleanup(: Define.
* elf64-mips.c (bfd_elf64_close_and_cleanup): Define.
* elfn32-mips.c (bfd_elf32_close_and_cleanup(: Define.
* elfxx-mips.c (struct mips_hi16): Move earlier.
(mips_hi16_list): Move to..
(struct mips_elf_obj_tdata): ..here.
(_bfd_mips_elf_close_and_cleanup): New function.
(_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc),
(_bfd_elf_mips_get_relocated_section_contents): Adjust uses of
mips_hi16_list.
* elfxx-mips.h (_bfd_mips_elf_close_and_cleanup): Declare.

Automatic date update in version.in

libctf: remove unnecessary zstd constructs

This patch is essentially a revert of
commit-id: 8818c80cbd4116ef5af171ec47c61167179e225c
(libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true)

As the specific configure check now uses libtool, this explicit mention of the
dependency $ZSTD_LIBS is not needed anymore.

ChangeLog:

* libctf/Makefile.in: Regenerated.
* libctf/aclocal.m4: Likewise.
* libctf/config.h.in: Likewise.
* libctf/configure: Likewise.
* libctf/configure.ac: Remove ZSTD_LIBS from LIBS.  Cleanup
unused AC_ZSTD.

libctf: remove AC_CONFIG_MACRO_DIR

ACLOCAL_AMFLAGS is being set already.  So using AC_CONFIG_MACRO_DIR is
unnecessary.

ChangeLog:

* libctf/configure: Regenerated.
* libctf/configure.ac: remove AC_CONFIG_MACRO_DIR usage.

libctf: remove unnecessary zlib constructs

This dependency is managed via libtool.  So explicit addition to LDFLAGS
and LIBS is not necessary anymore.

ChangeLog:

* libctf/configure: Regenerated.
* libctf/configure.ac: remove zlib from LDFLAGS and LIBS.

[gdb/testsuite] Fix PR20630 regression test in gdb.base/printcmds.exp

On s390x-linux, I run into:
...
(gdb) print {unsigned char}{65}^M
$749 = 0 '\000'^M
(gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
...

In contrast, on x86_64-linux, we have:
...
(gdb) print {unsigned char}{65}^M
$749 = 65 'A'^M
(gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
...

The first problem here is that the test is supposed to be a regression test
for PR20630, which can be reproduced (for an unfixed gdb) like this:
...
(gdb) p {unsigned char[]}{0x17}
gdbtypes.c:4641: internal-error: copy_type: \
  Assertion `TYPE_OBJFILE_OWNED (type)' failed.
...
but it's not due to insufficient quoting (note the dropped '[]').

That's easy to fix, but after that we have on s390 (big endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = ""^M
...
and on x86_64 (little endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = "A"^M
...

Fix this by using 0xffffffff, such that in both cases we have:
...
(gdb) print {unsigned char[]}{0xffffffff}^M
$749 = "\377\377\377\377"^M
...

Tested on x86_64-linux and s390x-linux.

PR29893, buffer overflow in display_debug_addr

PR 29893
* dwarf.c (display_debug_addr): Sanity check dwarf5 unit_length
field.  Don't read past end.

Another Rust operator precedence bug

My earlier patch to fix PR rust/29859 introduced a new operator
precedence bug in the Rust parser.  Assignment operators are
right-associative in Rust.  And, while this doesn't often matter, as
Rust assignments always have the value (), still as a matter of
principle we should get this correct.

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

[gdb/testsuite] Fix gdb.base/write_mem.exp for big endian

On s390x-linux (big endian), I run into:
...
(gdb) x /xh main^M
0x1000638 <main>:       0x0000^M
(gdb) FAIL: gdb.base/write_mem.exp: x /xh main
...

In contrast, on x86_64-linux (little endian), we have the expected:
...
(gdb) x /xh main^M
0x4004a7 <main>:        0x4242^M
(gdb) PASS: gdb.base/write_mem.exp: x /xh main
...

The problem is that the test-case hard-codes expectations about endiannes by
writing an int-sized value (4 bytes in this case) and then printing only a
halfword by using "/h" (so, two bytes).

If we print 4 bytes, we have for s390x:
...
0x1000638 <main>:       0x00004242^M
...
and for x86_64:
...
0x4004a7 <main>:        0x00004242^M
...

Fix this by removing the "/h".

Tested on x86_64-linux and s390x-linux.

gdb: fix possible use-after-free when executing commands

In principle, `execute_command()` does following:

   struct cmd_list_element *c;
   c = lookup_cmd ( ... );
   ...
   /* If this command has been pre-hooked, run the hook first.  */
   execute_cmd_pre_hook (c);
   ...
   /* ...execute the command `c` ...*/
   ...
   execute_cmd_post_hook (c);

This may lead into use-after-free error.  Imagine the command
being executed is a user-defined Python command that redefines
itself.  In that case, struct `cmd_list_element` pointed to by
`c` is deallocated during its execution so it is no longer valid
when post hook is executed.

To fix this case, this commit looks up the command once again
after it is executed to get pointer to (possibly newly allocated)
`cmd_list_element`.

x86: further re-work insn/suffix recognition to also cover MOVSX

PR gas/29524

Having templates with a suffix explicitly present has always been
quirky. After prior adjustment all that's left to also eliminate the
anomaly from move-with-sign-extend is to consolidate the insn templates
and to make may_need_pass2() cope (plus extend testsuite coverage).

x86: drop (now) stray IsString

The need for them on the operand-less string insns has gone away with
the removal of maybe_adjust_templates() and associated logic. Since
i386_index_check() needs adjustment then anyway, take the opportunity
and also simplify it, possible again as a result of said removal (plus
the opcode template adjustments done here).

x86: move bad-use-of-TLS-reloc check

Having it in match_template() is unhelpful. Neither does looking for the
next template to possibly match make any sense in that case, nor is the
resulting diagnostic making clear what the problem is.

While moving the check, also generalize it to include all SIMD and VEX-
encoded insns. This way an existing conditional can be re-used in
md_assemble(). Note though that this still leaves a lof of insns which
are also wrong to use with these relocations.

Further fold the remaining check (BFD_RELOC_386_GOT32) with the XRELEASE
related one a few lines down. This again allows re-using an existing
conditional.

x86-64: allow HLE store of accumulator to absolute 32-bit address

In commit 1212781b35c9 ("ix86: allow HLE store of accumulator to
absolute address") I was wrong to exclude 64-bit code. Dropping the
check also leads to better diagnostics in 64-bit code ("MOV", after
all, isn't invalid with "XRELEASE").

While there also limit the amount of further checks done: The operand
type checks that were there were effectively redundant with other ones
anyway, plus it's quite fine to also have "xrelease mov <disp>, %eax"
look for the next MOV template (in fact again also improving
diagnostics).

ix86: don't recognize/derive Q suffix in the common case

Have its use, except where actually legitimate, result in the same "only
supported in 64-bit mode" diagnostic as emitted for other 64-bit only
insns. Also suppress deriving of the suffix in Intel mode except in the
legitimate cases. This in exchange allows dropping the respective code
from match_template().

To maintain reasonable diagnostics (in particular to avoid "`mov' is
only supported in 64-bit mode" on the SIMD forms of MOVQ) we need to
defer parse_insn()'s emitting of errors unrelated to prefix parsing.
Utilize i.error just like match_template() does.

Oddly enough despite gcc's preference towards FILDQ and FIST{,T}Q we
had no testcase whatsoever for these. Therefore such tests are being
added. Note that the removed line in the x86-64-lfence-load testcase
was redundant with the exact same one a few lines up.

x86: re-work insn/suffix recognition

Having templates with a suffix explicitly present has always been
quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
a suitable template _and_ didn't itself already need to trim off a
suffix to find a match at all. This requires error reporting adjustments
(albeit luckily fewer than I was afraid might be necessary), as errors
previously reported during matching now need deferring until after the
2nd pass (because, obviously, we must not emit any error if the 2nd pass
succeeds). While also related to PR gas/29524, it was requested that
move-with-sign-extend be left as broken as it always was.

PR gas/29525
Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
templates taking operands, mixed IsString/non-IsString template groups
(with memory operands) cannot occur anymore. With that
maybe_adjust_templates() becomes unnecessary (and is hence being
removed).

PR gas/29526
Note further that while the additions to the intel16 testcase aren't
really proper Intel syntax, we've been permitting all of those except
for the MOVD variant. The test therefore is to avoid re-introducing such
an inconsistency.

x86: constify parse_insn()'s input

The function doesn't alter its input buffer: Reflect this in its
prototype. To avoid using any kind of cast, simply calculate the update
of "line" from the function's input and output.

x86: revert disassembler parts of "x86: Allow 16-bit register source for LAR and LSL"

This reverts the disassembler parts of 859aa2c86dc9 ("x86: Allow 16-bit
register source for LAR and LSL"), adjusting testcases as necessary.
That change was itself a partial revert of c9f5b96bdab0 ("x86: correct
handling of LAR and LSL"), without actually saying so. While the earlier
commit was properly agreed upon, the partial revert was not, and hence
should not have been committed. This is even more so that the revert
part of that change wasn't even necessary to address PR gas/29844.

PR29892, Field file_table of struct module is uninitialized

PR 29892
* vms-alphs.c (new_module): Use bfd_zmalloc to alloc file_table.
(parse_module): Rewrite file_table reallocation code and clear.

Lack of bounds checking in vms-alpha.c parse_module

PR 29873
PR 29874
PR 29875
PR 29876
PR 29877
PR 29878
PR 29879
PR 29880
PR 29881
PR 29882
PR 29883
PR 29884
PR 29885
PR 29886
PR 29887
PR 29888
PR 29889
PR 29890
PR 29891
* vms-alpha.c (parse_module): Make length param bfd_size_type.
Delete length == -1 checks.  Sanity check record_length.
Sanity check DST__K_MODBEG, DST__K_RTNBEG, DST__K_RTNEND lengths.
Sanity check DST__K_SOURCE and DST__K_LINE_NUM elements
before accessing.
(build_module_list): Pass dst_section size to parse_module.

PR29872, uninitialised value in display_debug_lines_decoded dwarf.c:5413

Plus segvs if the C-library doesn't handle printf %s of NULL.

PR 29872
* dwarf.c (null_name): New function.
(process_debug_info): Use it here..
(display_debug_lines_raw): ..and here..
(display_debug_lines_decoded): ..and here.  xcalloc directory_table.
Simplify xcalloc of file_table.

gas/codeview: avoid "shadowing" of glibc function name

While not "index" this time, old enough glibc also has an (unguarded)
declaration of fileno() in stdio.h, which triggers a "shadows a global
declaration" warning with our choice of warning level and with at least
some gcc versions.

x86: generate template sets data at build time

Speed up gas startup by avoiding runtime allocation of the instances of
type "templates". At the same time cut the memory requirement to just
very little over half (not even accounting for any overhead
notes_alloc() may incur) by reusing the "end" slot of a preceding entry
for the "start" slot of the subsequent one.

x86: drop sentinel from i386_optab[]

Now that the table is local to gas, ARRAY_SIZE() can be used to
determine the end of the table. Re-arrange the processing loop in
md_begin() accordingly, at the same time folding the two calls to
notes_alloc() into just one.

x86: add generated tables dependency check to gas

As requested by H.J., just for the sake of people potentially building
in gas/ alone, add a check that the generated files in opcodes/ are
actually up-to-date. Personally I think this should at best be a
warning, but I can see how this may not be easily noticable among other
make output (depending in particular on the verbosity level).

x86: break gas dependency on libopcodes

gas doesn't use anything from libopcodes anymore - suppress linking in
that library.

x86: remove i386-opc.c

Remove the now empty i386-opc.c. To compensate, tie table generation in
opcodes/ to the building of i386-dis.o, despite the file not really
depending on the generated data.

x86: instantiate i386_{op,reg}tab[] in gas instead of in libopcodes

Unlike many other architectures, x86 does not share an opcode table
between assembly and disassembly. Any consumer of libopcodes would only
ever access one of the two. Since gas is the only consumer of the
assembly data, move it there. While doing so mark respective entities
"static" in i386-gen (we may want to do away with i386_regtab_size
altogether).

This also shrinks the number of relocations to be processed for
libopcodes.so by about 30%.

Automatic date update in version.in

PR29870, objdump SEGV in display_debug_lines_decoded dwarf.c:5524

DWARF5 directory and file table allow more opportunity for fuzzers
to break things.  There are likely other places in dwarf.c that should
be fixed too.

PR 29870
* dwarf.c (display_debug_lines_decoded): Handle NULL file_table
name entry.

Automatic date update in version.in

[gdb/tdep] Fix larl handling in s390_displaced_step_fixup

On s390x-linux with target board unix/-m31, I run into:
...
(gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length
print ptr^M
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
(gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr
...

A minimal example is:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+file scm-lazy-string
+break main
Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23.
+run

Breakpoint 1, main () at scm-lazy-string.c:23
23        const char *ptr = "pointer";
+step
24        const char array[] = "array";
+print ptr
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
...

If we delete the breakpoint after running to it, we have instead the expected:
...
+delete
+step
24        const char array[] = "array";
+print ptr
$1 = 0x4006b0 "pointer"
...

The problem is in displaced stepping, forced by the presence of the breakpoint,
when stepping over this insn:
...
  0x4005d2 <main+10>      larl    %r1,0x4006b0
...

With normal stepping we have:
...
(gdb) p /x $r1
$2 = 0x3ff004006b0
...
but with displaced stepping we have instead (note the 0x80000000 difference):
...
(gdb) p /x $r1
$1 = 0x3ff804006b0
(gdb)
...

The difference comes from this code in s390_displaced_step_fixup:
...
  /* Handle LOAD ADDRESS RELATIVE LONG.  */
  else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2))
    {
      /* Update PC.  */
      regcache_write_pc (regs, from + insnlen);
      /* Recompute output address in R1.  */
      regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
                                      amode | (from + i2 * 2));
    }
...
where the "amode |" adds the 0x80000000.

Fix this by removing the "amode |".

Tested on s390-linux, with native and target board unix/-m31.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>

Automatic date update in version.in

objdump: sframe: fix memory leaks

ChangeLog:

* binutils/objdump.c (dump_section_sframe): free up contents and
SFrame decoder context on exit.

libsframe: rename API sframe_fde_func_info to sframe_fde_create_func_info

The new name better reflects the purpose of the function.

ChangeLog:

* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use new
name.
* libsframe/sframe.c (sframe_fde_create_func_info): Rename
sframe_fde_func_info to this.
* libsframe/testsuite/libsframe.encode/encode-1.c: Use new name.

include/ChangeLog:

* sframe-api.h (sframe_fde_create_func_info): Rename
sframe_fde_func_info to this.

gas: sframe: fine tune the fragment fixup for SFrame func info

SFrame function info is an unsigned 8-bit field comprising of the following
(from LSB to MSB):
  - 4-bits: FRE type
  - 1-bit: FRE start address encoding
  - 3-bits: Unused

At the moment, the most-significat 4-bits are zero (The FRE start
address encoding of SFRAME_FDE_TYPE_PCINC has a value of zero, and the upper
3-bits are unused). So the current implementation works without this patch.

To be precise, however, the fragment fixup logic is meant to fixup only the
least-significant 4-bits (i.e., only the FRE type needs to be updated
according to the function size).

This patch makes the gas implementation a bit more resilient: In the
future, when the format does evolve to make use of the currently unused
3-bits in various ways, the values in those 3-bits can be propagated
unchanged while the fragment fixup continues to update the lowermost
4-bits to indicate the selected FRE type.

ChangeLog:

* gas/gen-sframe.c (create_func_info_exp): New definition.
(output_sframe_funcdesc): Call create_func_info_exp.
* gas/sframe-opt.c (sframe_estimate_size_before_relax): The
associated fragment uses O_modulus now.
(sframe_convert_frag): Adjust the fragment fixup code according
to the new composite exp.

sframe: gas: libsframe: define constants and remove magic numbers

Define constants in sframe.h for the various limits associated with the
range of offsets that can be encoded in the start address of an SFrame
FRE. E.g., sframe_frame_row_entry_addr1 is used when start address
offset can be encoded as 1-byte unsigned value.

Update the code in gas to use these defined constants as it checks for
these limits, and remove the usage of magic numbers.

ChangeLog:

* gas/sframe-opt.c (sframe_estimate_size_before_relax):
(sframe_convert_frag): Do not use magic numbers.
* libsframe/sframe.c (sframe_calc_fre_type): Likewise.

include/ChangeLog:

* sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): New constant.
(SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
(SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.

sframe.h: make some macros more precise

include/ChangeLog:

* sframe.h (SFRAME_V1_FUNC_INFO): Use specific bits only.
(SFRAME_V1_FRE_INFO): Likewise.

libsframe: minor formatting nits

ChangeLog:

* libsframe/sframe.c: Fix formatting nits.

[aarch64] Add TPIDR2 register support for Linux

With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:

https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/

From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.

With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.

That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.

In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.

The core file read/write code has been updated to support TPIDR2 as well.

On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.

It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.

This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.

The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.

PR28306, segfault in _bfd_mips_elf_reloc_unshuffle

Access to section data during relocation processing should be bounds
checked, as it is in bfd_perform_relocation.  bfd_perform_relocation
does these checks after any special_function is called.  So a reloc
special_function needs to do its own bounds checking before accessing
section data.  This patch adds many such checks to the mips backend.

Checking mips relocs is not without some difficulty.  See the comment
in _bfd_mips_reloc_offset_in_range.  In a multitple reloc sequence
applied to the same location, relocs that may appear somewhere other
than the last one of the sequence need to be treated specially since
they apply to the addend for the next relocation rather than the
section contents.  If the addend is in the section then it needs to be
checked but not when the addend is in the reloc.  check_inplace
handles this situation.  _bfd_mips_reloc_offset_in_range with
check_shuffle handles the case where contents are shuffled before
applying the relocation.

PR 28306
* elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Check reloc
address using _bfd_mips_reloc_offset_in_range.
(gprel32_with_gp, mips16_gprel_reloc): Likewise.
* elf64-mips.c (mips_elf64_gprel32_reloc): Likewise.
(mips16_gprel_reloc): Likewise.
* elfn32-mips.c (mips16_gprel_reloc): Likewise.
(gprel32_with_gp): Check reloc address using
bfd_reloc_offset_in_range.
* elfxx-mips.h (enum reloc_check): Define.
(_bfd_mips_reloc_offset_in_range): Declare.
* elfxx-mips.c (needs_shuffle): New function.
(_bfd_mips_elf_reloc_unshuffle, _bfd_mips_elf_reloc_shuffle): Use it.
(_bfd_mips_reloc_offset_in_range): New function.
(_bfd_mips_elf_gprel16_with_gp): Move reloc address checks to
partial_inplace handling.  Use bfd_reloc_offset_in_range.
(_bfd_mips_elf_lo16_reloc): Check reloc address using
bfd_reloc_offset_in_range.
(_bfd_mips_elf_generic_reloc): Check reloc address using
_bfd_mips_reloc_offset_in_range.
(mips_elf_calculate_relocation): Check reloc address before calling
mips_elf_nullify_got_load.
(_bfd_mips_elf_check_relocs): Likewise.
(mips_elf_read_rel_addend): Add sec param, check reloc address
before reading.  Adjust callers.
(mips_elf_add_lo16_rel_addend): Add sec param, adjust callers.

[gdb/testsuite] Fix gdb.guile/scm-symtab.exp for ppc64le

On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2
guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M
= #f^M
(gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
...

The problem is as follows: the instructions for the call to func2 are:
...
    1000070c:   39 00 00 48     bl      10000744 <func1>
    10000710:   00 00 00 60     nop
    10000714:   59 00 00 48     bl      1000076c <func2>
    10000718:   00 00 00 60     nop
    1000071c:   00 00 20 39     li      r9,0
...
and the corresponding line number info is:
...
scm-symtab.c:
File name     Line number    Starting address    View    Stmt
scm-symtab.c           42          0x1000070c               x
scm-symtab.c           43          0x10000714               x
scm-symtab.c           44          0x1000071c               x
...

The test-case looks at the line numbers for two insns:
- the insn of the call to func2 (0x10000714), and
- the insn after that (0x10000718),
and expects the line number of the latter to be greater than the line number
of the former.

However, both insns have the same line number: 43.

Fix this by replacing ">" with ">=".

Tested on x86_64-linux and powerpc64le-linux.

Automatic date update in version.in

x86-64: Remove BND from 64-bit IBT PLT

Since MPX support has been removed from x86-64 psABI, remove BND from
64-bit IBT PLT by using x32 IBT PLT.

bfd/

PR ld/29851
* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Also check
x32 IBT PLT for 64-bit.
(elf_x86_64_link_setup_gnu_properties): Always use x32 IBT PLT.

ld/

PR ld/29851
* testsuite/ld-x86-64/ibt-plt-1.d: Updated.
* testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2b.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2c.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2d.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-3a.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-3b.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-3c.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-3d.d: Likewise.
* testsuite/ld-x86-64/plt-main-ibt-x32.dd: Moved to ...
* testsuite/ld-x86-64/plt-main-ibt.dd: This.
* testsuite/ld-x86-64/x86-64.exp: Don't use plt-main-ibt-x32.dd.

[gdb/testsuite] Require debug info for gdb.tui/tui-layout-asm-short-prog.exp

When running test-case gdb.tui/tui-layout-asm-short-prog.exp on SLE-12-SP3
aarch64, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents again
...
due to:
...
(gdb) file tui-layout-asm-short-prog^M
Reading symbols from tui-layout-asm-short-prog...^M
(No debugging symbols found in tui-layout-asm-short-prog)^M
...

I managed to reproduce the same behaviour on openSUSE Leap 15.4 x86_64, by
removing the debug option.

Fix this by making the test-case unsupported if no debug info is found.

Tested on x86_64-linux.

gdb/testsuite: update a pattern in gdb_file_cmd

When building GDB with the following CFLAGS and CXXFLAGS as part of
configure line:

    CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11

Then run the selftest.exp, I see:

======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
WARNING: Couldn't test self

                === gdb Summary ===

 # of unexpected failures        1
/home/lee/dev/binutils-gdb/gdb/gdb version  13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======

It is the fact that when I use the previously mentioned CFLAGS and
CXXFLAGS as part of the configuration line, the default value (-O2 -g)
is overridden, then GDB has no debug information.  When there's no debug
information, GDB should not run the testcase in selftest.exp.

The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
get the right value ("nodebug") during the gdb_file_cmd procedure.

That's because in this commit,

  commit 3453e7e409f44a79ac6695589836edb8a49bfb08
  Date:   Sat May 19 11:25:20 2018 -0600

    Clean up "Reading symbols" output

It changed "no debugging..." to "No debugging..." which causes the above
problem.  This patch only updates the corresponding pattern to fix this
issue.

With this patch applied, I see:

======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...

                === gdb Summary ===

 # of untested testcases         1
/home/lee/dev/binutils-gdb/gdb/gdb version  13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======

Tested on x86_64-linux.

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

Update the description of the linker script's TYPE directive.

PR 29861
* ld.texi (Output Section Type): Note that setting the output
section type only works if the section contains untyped data.

gdb: skip objfiles with no BFD in DWARF unwinder

While playing with JIT reader I experienced GDB to crash on null-pointer
dereference when stepping through non-jitted code.

The problem was that dwarf2_frame_find_fde () assumed that all objfiles
have BFD but that's not always true. To address this problem, this
commit skips such objfiles.

To test the fix we put breakpoint in jit_function_add (). The JIT reader
does not know how unwind this function so unwinding eventually falls
back to DWARF unwinder which in turn iterates over objfiles. Since the
the code is jitted, it is guaranteed it would eventually process JIT
objfile.

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

libctf: avoid potential double free

* ctf-link.c (ctf_link_add_cu_mapping): Set t NULL after free.

Automatic date update in version.in

PowerPC: Add support for RFC02655 - Saturating Subtract Instruction

opcodes/
* ppc-opc.c (XOL): New define.
(XOL_MASK): Likewise.
(powerpc_opcodes): Add subfus, subfus., subwus, subwus., subdus, subdus.

gas/
* testsuite/gas/ppc/rfc02655.s: New test.
* testsuite/gas/ppc/rfc02655.d: Likewise
* testsuite/gas/ppc/future-raw.s: Likewise.
* testsuite/gas/ppc/future-raw.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run them.

PowerPC: Add support for RFC02656 - Enhanced Load Store with Length Instructions

opcodes/
* ppc-opc.c (PPCVSXF): New define.
(powerpc_opcodes): Add lxvrl, lxvrll, lxvprl, lxvprll, stxvrl,
stxvrll, stxvprl, stxvprl.

gas/
* testsuite/gas/ppc/rfc02656.s: New test.
* testsuite/gas/ppc/rfc02656.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.