svp64: align on 64-byte boundary

ppc-opc: sync instructions

all: sync recent ff/pi/lf updates

svp64: mark RA0 operands; introduce RT0 operand

ppc: support binlog instructions

ppc: support ternlogi instructions

ppc: support ffadds instruction

ppc: support fdmadds instruction

ppc: support ffnmadds instruction

ppc: support ffnmsubs instruction

ppc: support ffmadds instruction

ppc: support ffmsubs instruction

ppc: support minmax aliases

ppc: support minmax instruction

ppc: support maddedus instruction

ppc: support dsrd instruction

ppc: support dsld instruction

ppc-opc.c: place new instructions at SFFS level

svp64: sync specifiers

ppc/svp64: support optional operands disassembly

ppc/svp64: disassemble branch mode

ppc/svp64: disassemble CR op mode

ppc/svp64: disassemble ld/st idx mode

ppc/svp64: disassemble ld/st imm mode

ppc/svp64: disassemble normal mode

ppc/svp64: disassemble SVP64 operands

ppc/svp64: disassemble SVP64 name

ppc/svp64: obtain SVP64 disassembly context

ppc/svp64: share SVP64 context via libopcodes

ppc/svp64: introduce SVP64 opcode lookup

ppc: decouple print_insn_powerpc_opcode routine

ppc/svp64: reuse md_parse_name in md_operand

ppc/svp64: introduce alias for 1<<%r3 predicate

ppc/svp64: allow predicate macro expansion

ppc/svp64: introduce SVP64 name parser

ppc/svp64: allow w/dw/sw macro expansion

ppc/svp64: remap operands and build instructions

ppc/svp64: support SVP64 vectors

ppc: refactor assembly logic

ppc/svp64: validate and fix modes

ppc/svp64: validate SVP64 context

ppc/svp64: support crm mode

ppc/svp64: support mr/mrr modes

ppc/svp64: support ff/pr modes

ppc/svp64: support zz/dz/sz specifier

ppc/svp64: support sat specifier

ppc/svp64: support sea specifier

ppc/svp64: support els specifier

ppc/svp64: support w/dw/sw modes

ppc/svp64: support vec2/vec3/vec4 modes

ppc/svp64: support m/dm/sm modes

ppc/svp64: introduce svp64_decode stub

ppc/svp64: setup SVP64 opcodes table

opcodes: introduce SVP64 sources

opcodes: introduce SVP64 headers

ppc/svp64: introduce svp64_assemble stub

ppc: share pd_reg definition via libopcodes

ppc/svp64: support shadd/shadduw instructions

ppc/svp64: support divmod2du instruction

ppc/svp64: support maddedu instruction

ppc/svp64: support fptrans instructions

ppc/svp64: support bmask instruction

ppc/svp64: support absd instructions

ppc/svp64: support cprop instructions

ppc/svp64: support avgadd instructions

ppc/svp64: support fishmv instruction

ppc/svp64: support fmvis instruction

ppc/svp64: support svshape2 instruction

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/remap/#svshape
https://libre-soc.org/openpower/sv/remap/#svshape2
https://libre-soc.org/openpower/isa/simplev/

ppc: decouple SFFS and SVP64 extensions

Remove path name from test case

'runtest' complains about a path in a test name, from the new test
case py-missing-debug.exp.

This patch fixes the problem by providing an explicit test name to
gdb_test.  I chose something very basic because the block in question
is already wrapped in with_test_prefix.

Remove some redundant "break"s

I found some "break" statements that follow "return" or a call to a
noreturn function.  These aren't needed, and the compiler would warn
if they were.  So, this patch removes them.

Tested by rebuilding.

Filter invalid encodings from Linux thread names

On Linux, a thread can only be 16 bytes (including the trailing \0).
A user sent in a test case where this causes a truncated UTF-8
sequence, causing gdbserver to create invalid XML.

I went back and forth about different ways to solve this, and in the
end decided to fix it in gdbserver, with the reason being that it
seems important to generate correct XML for the <thread> response.

I am not totally sure whether the call to setlocale could have
unplanned consequences.  This is needed, though, for nl_langinfo to
return the correct result.

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

Update gdb.Symbol.is_variable documentation

Kévin found a bug in an earlier version of this series that was based
on a misconception I had about Symbol.is_variable.  This patch fixes
the documentation to explain the method a bit better.

Approved-By: Eli Zaretskii <eliz@gnu.org>

Handle the static link in FrameDecorator

A co-worker requested that the DAP scope for a nested function's frame
also show the variables from outer frames.  DAP doesn't directly
support this notion, so this patch arranges to put these variables
into the inner frames "Locals" scope.

I chose to do this only for DAP.  For CLI and MI, gdb currently does
not do this, so this preserves the behavior.

Note that an earlier patch (see commit 4a1311ba) removed some code
that seemed to do something similar.  However, that code did not
actually work.

Fix a bug in DAP scopes code

While working on static links, I noticed that the DAP scopes code does
not handle the scenario where a frame decorator returns None.  This
situation should be handled identically to a frame decorator returning
an empty iterator.

Add gdb.Frame.static_link method

This adds a new gdb.Frame.static_link method to the gdb Python layer.
This can be used to find the static link frame for a given frame.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Move follow_static_link to frame.c

This moves the follow_static_link function to frame.c and exports it
for use elsewhere.  The API is changed slightly to make it more
generically useful.

Add block::function_block

This adds the method block::function_block, to easily access a block's
enclosing function block.

Add two convenience methods to block

This adds a couple of convenience methods, block::is_static_block and
block::is_global_block.

gdb/MAINTAINERS: add Guinevere Larsen as record-full maintainer

Change-Id: I67d8361560ce0fa553b2983184c9d18df8dbeb4a

gdb/MAINTAINERS: add Luis Machado as global maintainer

Change-Id: I211d64393f5c0da3c9ce1fcf5486504d34ed38f4

gdb/MAINTAINERS: add John Baldwin as global maintainer

Change-Id: Ic9164fd19c3da1381302a17176e8f0f814e9ac6c

gdb: normalize whitespaces in MAINTAINERS

Replace some spaces with tabs.

Change-Id: I89bbabd6610219649e7e99cd0dd7b0ed66d69b09

[gdb/tui] Factor out tui_noscroll_window et al

I noticed that tui_locator_window has an empty do_scroll_vertical and
do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't
have:
...
  bool can_scroll () const override
  {
    return false;
  }
...

I suspect that it probably doesn't matter, but regardless it's good to have
the same implementations of basic properties in all windows.

Ensure this by adding a class tui_noscroll_window, that has:
- an empty do_scroll_vertical and do_scroll_horizontal, and
- a can_scroll returning false
which both tui_locator_window and tui_cmd_window inherit.

Make all methods final to ensure no accidental overrides are left in the
inheriting classes.

Likewise add new classes representing basic window properties:
- tui_nofocus_window,
- tui_oneline_window,
- tui_nobox_window,
- tui_norefresh_window, and
- tui_always_visible_window.

The changes are only a refactoring, apart from adding the "final", which does
limit the range of behaviours for subclasses.

Tested on x86_64-linux.

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

gdb: refactor make-target-delegates.py's ARGTYPES

Refactor the ARGTYPES regular expression in make-target-delegates.py
to eliminate '.*' for better control on what is matched.  Also,
simplify the "E" match group, for which the optional SYMBOL becomes
redundant because that case can be matched by the "T" group.

After applying this patch, running './make-target-delegates.py' does not
change anything in 'target-delegates.c'.

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

gdb: regenerate target-delegates.c

I ran './make-target-delegates.py' and there is one minor difference,
where an older style declaration is converted to a newer
initialization style.  Add this change.

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

[gdb/testsuite] Fix gdb.threads/stepi-over-clone.exp regexp

I ran into the following FAIL:
...
(gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
continue^M
Continuing.^M
^M
Catchpoint 2 (call to syscall clone), clone () at \
  ../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M
warning: 78     ../sysdeps/unix/sysv/linux/x86_64/clone.S: \
  No such file or directory^M
(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
...

All but one regexps in the .exp file use "clone\[23\]?" with "?" to
also accept "clone", except the failing case.  This commit fixes that
case to also use "?".

Furthermore, there are FAILs like this:
...
(gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \
   non-stop=on: displaced=off: i=0: continue
stepi^M
[New Thread 0x7ffff7ff8700 (LWP 15301)]^M
Hello from the first thread.^M
78      in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M
(gdb) XXX: Consume the initial command
XXX: Consume new thread line
XXX: Consume first worker thread message
FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \
  displaced=off: i=0: stepi
...
because this output is expected instead:
...
Hello from the first thread.^M
0x00000000004212cd in clone3 ()^M
...

The root cause for the difference is the presence of .debug_line info for
clone.

Fix this by updating the relevant regexps.

Tested on x86_64-linux, specifically:
- openSUSE Leap 15.4 (where the FAILs where observed), and
- openSUSE Tumbleweed (where the FAILs where not observed).

Co-Authored-By: Pedro Alves <pedro@palves.net>
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c

gdb: implement missing debug handler hook for Python

This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.

The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.

The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:

  info missing-debug-handlers
  enable missing-debug-handler LOCUS HANDLER
  disable missing-debug-handler LOCUS HANDLER

To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help.  Here is a
minimal handler that does nothing useful:

  import gdb
  import gdb.missing_debug

  class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
      def __init__(self):
          super().__init__("my_first_handler")

      def __call__(self, objfile):
          # This handler does nothing useful.
          return None

  gdb.missing_debug.register_handler(None, MyFirstHandler())

Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.

By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.

Possible return values from a handler:

  - None: This means the handler couldn't help.  GDB will call other
          registered handlers to see if they can help instead.

  - False: The handler has done all it can, but the debug information
           for the objfile still couldn't be found.  GDB will not call
   any other handlers, and will continue without the debug
   information for objfile.

  - True: The handler has installed the debug information into a
          location where GDB would normally expect to find it.  GDB
  should look again for the debug information.

  - A string: The handler can return a filename, which is the file
              containing the missing debug information.  GDB will load
      this file.

When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies.  It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.

Handlers can be registered globally, or per program space.  GDB checks
the handlers for the current program space first, and then all of the
global handles.  The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.

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

gdb: add an extension language hook for missing debug info

This commit adds a new extension_language_ops hook which allows an
extension to handle the case where GDB can't find a separate debug
information file for a particular objfile.

This commit doesn't actually implement the hook for any of GDB's
extension languages, the next commit will do that.  This commit just
adds support for the hook to extension-priv.h and extension.[ch], and
then reworks symfile-debug.c to call the hook.

Right now the hook will always return its default value, which means
GDB should do nothing different.  As such, there should be no user
visible changes after this commit.

I'll give a brief description of what the hook does here so that we
can understand the changes in symfile-debug.c.  The next commit adds a
Python implementation for this new hook, and gives a fuller
description of the new functionality.

Currently, when looking for separate debug information GDB tries three
things, in this order:

  1. Use the build-id to find the required debug information,

  2. Check for .gnu_debuglink section and use that to look up the
  required debug information,

  3. Check with debuginfod to see if it can supply the required
  information.

The new extension_language_ops::handle_missing_debuginfo hook is
called if all three steps fail to find any debug information.  The
hook has three possible return values:

  a. Nothing, no debug information is found, GDB continues without the
  debug information for this objfile.  This matches the current
  behaviour of GDB, and is the default if nothing is implementing this
  new hook,

  b. Install debug information into a location that step #1 or #2
  above would normally check, and then request that GDB repeats steps
  #1 and #2 in the hope that GDB will now find the debug information.
  If the debug information is still not found then GDB carries on
  without the debug information.  If the debug information is found
  the GDB loads it and carries on,

  c. Return a filename for a file containing the required debug
  information.  GDB loads the contents of this file and carries on.

The changes in this commit mostly involve placing the core of
objfile::find_and_add_separate_symbol_file into a loop which allows
for steps #1 and #2 to be repeated.

We take care to ensure that debuginfod is only queried once, the first
time through.  The assumption is that no extension is going to be able
to control the replies from debuginfod, so there's no point making a
second request -- and as these requests go over the network, they
could potentially be slow.

The warnings that find_and_add_separate_symbol_file collects are
displayed only once assuming that no debug information is found.  If
debug information is found, even after the extension has operated,
then the warnings are not shown; remember, these are warnings from GDB
about failure to find any suitable debug information, so it makes
sense to hide these if debug information is found.

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

gdb: refactor objfile::find_and_add_separate_symbol_file

This is purely a refactoring commit.

This commit splits objfile::find_and_add_separate_symbol_file into
some separate helper functions.  My hope is that the steps for looking
up separate debug information are now clearer.

In a later commit I'm going to extend
objfile::find_and_add_separate_symbol_file, with some additional
logic, so starting with a simpler function will make the following
changes easier.

When reading objfile::find_and_add_separate_symbol_file after this
commit, you might be tempted to think that removing the `has_dwarf`
local variable would be a good additional cleanup.  After the next
commit though it makes more sense to retain this local, so I've left
this in place for now.

There should be no user visible changes after this commit.

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

gdb: merge debug symbol file lookup code from coffread & elfread paths

This commit merges the code that looks for and loads the separate
debug symbol files from coffread.c and elfread.c.  The factored out
code is moved into a new objfile::find_and_add_separate_symbol_file()
method.

For the elfread.c path there should be no user visible changes after
this commit.

For the coffread.c path GDB will now attempt to perform a debuginfod
lookup for the missing debug information, assuming that GDB can find a
build-id in the COFF file.

I don't know if COFF files can include a build-id, but I the existing
coffread.c code already includes a call to
find_separate_debug_file_by_build-id, so I know that it is at least OK
for GDB to ask a COFF file for a build-id.  If the COFF file doesn't
include a build-id then the debuginfod lookup code will not trigger
and the new code is harmless.

If the COFF file does include a build-id, then we're going to end up
asking debuginfod for the debug file.  As build-ids should be unique,
this should be harmless, even if debuginfod doesn't contain any
suitable debug data, it just costs us one debuginfod lookup, so I'm
not too worried about this for now.

As with the previous commit, I've done some minimal testing using the
mingw toolchain on a Linux machine, GDB seems to still access the
split debug information just fine.

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

gdb/coffread: bring separate debug file logic into line with elfread.c

In this commit:

  commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07
  Date:   Fri Feb 1 19:39:04 2013 +0000

the logic for when we try to load a separate debug file in elfread.c
was extended.  The new code checks that the objfile doesn't already
have a separate debug objfile linked to it, and that the objfile isn't
itself a separate debug objfile for some other objfile.

The coffread code wasn't extended at the same time.

I don't know if it's possible for the coffread code to get into the
same state where these checks are needed, but I don't see why having
these checks would be a problem.  In a later commit I plan to merge
this part of the elfread and coffread code, so bringing these two
pieces of code into line first makes that job easier.

I've tested this with a simple test binary compiled with the mingw
toolchain on a Linux host.  After compiling the binary and splitting
out the debug info GDB still finds and loads the separate debug info.

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

Fix another linker command line option that was not being recognised in its long form.

  PR 28910
  * lexsup.c (ld_options): Ensure that the --mri-script option is correctly recognised.

Improve objdump's handling of compressed sections.

  PR 31062
  * objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option.
  * NEWS: Mention the new feature.
  * doc/binutils.texi: Document the new feature.
  * testsuite/binutils-all/objdump.s: Update expected output.
  * testsuite/binutils-all/objdump.exp: Add test of -Z -s.
  * testsuite/binutils-all/objdump.Zs: New file.
  * readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions.  Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise.

Automatic date update in version.in

[gdb/tui] Don't include border_width in left_margin

Currently left_margin does not match its documentation:
...
  /* Return the size of the left margin space, this is the space used to
     display things like breakpoint markers.  */
  int left_margin () const
  { return box_width () + TUI_EXECINFO_SIZE + extra_margin (); }
...

It is stated that the left margin is reserved to display things, but
the box_width is not used for that.

Fix this by dropping box_width () from the left_margin calculation.

Tested on x86_64-linux.

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

[gdb/tui] Add tui_win_info::{box_width,box_size}

In tui_source_window::set_contents we have:
...
  /* Take hilite (window border) into account, when
     calculating the number of lines.  */
  int nlines = height - 2;
...

The '2' represents the total size of the window border (or box, in can_box
terms), in this case one line at the top and one line at the bottom.

Likewise, '1' is used to represent the width of the window border.

Introduce new functions:
- tui_win_info::box_width () and
- tui_win_info::box_size ()
that can be used instead instead of these hardcoded constants.

Implement these such that they return 0 when can_box () == false.

Tested patch completeness by making all windows unboxed:
...
@@ -85,7 +85,7 @@ struct tui_win_info
   /* Return true if this window can be boxed.  */
   virtual bool can_box () const
   {
-    return true;
+    return false;
   }

   int box_width () const
...
and test-driving TUI.

This required eliminating an assert in
tui_source_window_base::show_source_content, I've included that part as well.

Tested on x86_64-linux.

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

[gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_window

Currently the call to prefresh in tui_source_window_base::refresh_window looks
like:
...
  prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin,
    y + m_content.size (), x + left_margin + view_width - 1);
...

This is hard to parse.  It's not obvious what the arguments mean, and there's
repetition in the argument calculation.

Fix this by rewriting the call as follows:
- use sminrow, smincol, smaxrow and smaxcol variables for the last
  4 arguments, and
- calculate the smaxrow and smaxcol variables based on the sminrow and
  smincol variables.

Tested on x86_64-linux.

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

Fix the gdb.ada/inline-section-gc.exp test

The original intention of the test appears to be checking to make sure
setting a breakpoint in an inlined function didn't set multiple
breakpoints where one of them was at address 0.

The gdb.ada/inline-section-gc.exp test may pass or fail depending on the
version of gnat.  Per the discussion on IRC, the ada inlining appears to
have some target dependencies.  In this test there are two functions,
callee and caller. Function calee is inlined into caller.  The test sets
a breakpoint in function callee.  The reported location where the
breakpoint is set may be at the requested location in callee or the
location in caller after callee has been inlined.  The test needs to
accept either location as correct provided the breakpoint address is not
zero.

This patch checks to see if the reported breakpoint is in function callee
or function caller and fails if the breakpoint address is 0x0.  The line
number where the breakpoint is set will match the requested line if the
breakpoint location is reported is callee.adb.  If the breakpoint is
reported in caller.adb, the line number in caller is the breakpoint
location in callee where it is inlined into caller.

This patch fixes the single regression failure for the test on PowerPC.
It does not introduce any failures on X86-64.

GNU-ld: ARM: Issues when trying to set target output architecture

  PR 28910
  * lexsup.c (ld_options): Ensure that the --format option is correctly recognised.