gdb/csky just return type from csky_vector_type() for vector resgisters

Some gdb stubs may not describe the type for vector registers in the
tdesc-xml and only send bitsize="128", gdb can't deal with a reg
with default type int with bitsize==128. So Just return csky_vector_type()
for vector resgisters.

gdb/csky return type int32 for float and vector pseudo regs

When reg_nr is one of the float and vector pseudo registers,
return builtin_type (gdbarch)->builtin_int32 for it.

Automatic date update in version.in

[PR build/29791] gnulib: Disable _GL_ATTRIBUTE_DEALLOC on Solaris

gdbsupport compilation badly fails with GCC 12 on Solaris, with errors
like

../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
      |                                                                        ^
../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate

We've not yet been able to determine where the ambiguity actually lies,
so this patch works around the issue by disabling _GL_ATTRIBUTE_DEALLOC
on Solaris, at least as a workaround for GDB 13.

As Tom suggested in the PR, this is done using our infrastructure for
local gnulib patches.

Tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and
x86_64-pc-linux-gnu.

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

Fix sol-thread.c compilation on 32-bit Solaris

sol-thread.c fails to compile on 32-bit Solaris: there are several
instances of

In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203,
                 from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28,
                 from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=]
  416 |         warning (_("Specified thread %ld seems to have terminated"),
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29:
note: in definition of macro ‘_’
   28 | # define _(String) gettext (String)
      |                             ^~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format
string is defined here
  416 |         warning (_("Specified thread %ld seems to have terminated"),
      |                                      ~~^
      |                                        |
      |                                        long int
      |                                      %lld

Fixed by using pulongest () instead.

Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11,
sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with
Simon's patch for PR build/29798).

Automatic date update in version.in

Add missing gdb_prompt in ctxobj.exp to avoid random failure, fix typo.

ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.

Also fixed a typo in a comment.

Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum $_hit_locno PR breakpoints/12464

This implements the request given in PR breakpoints/12464.

Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
  Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5

This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
  Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5

In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
  locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.

Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.

$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
   disable $_hit_bpnum.$_hit_locno

In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
  disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.

This also fixes a strange behaviour: when a breakpoint X has only
one location,
  enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.

The changes in RFA v4 handle the comments of Tom Tromey:
 - Changed convenience var names from $bkptno/$locno to
   $_hit_bpnum/$_hit_locno.
 - updated the tests and user manual accordingly.
   User manual also explictly describes that $_hit_locno is set to 1
   for a breakpoint with a single location.
 - The variable values are now set in bpstat_do_actions_1 so that
   they are set for silent breakpoints, and when several breakpoints
   are hit at the same time, that the variables are set to the printed
   breakpoint.

The changes in RFA v3 handle the additional comments of Eli:
 GDB/NEW:
  - Use max 80-column
  - Use 'code location' instead of 'location'.
  - Fix typo $bkpno
  - Ensure that disable $bkptno and disable $bkptno.$locno have
    each their explanation inthe example
  - Reworded the 'breakpoint-hit' paragraph.
 gdb.texinfo:
  - Use 'code location' instead of 'location'.
  - Add a note to clarify the distinction between $bkptno and $bpnum.
  - Use @kbd instead of examples with only one command.

Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
  - Use %s for the result of paddress
  - Use bkptno_numopt_re instead of 2 different -re cases
  - use C@t{++}
  - Add index entries for $bkptno and $locno
  - Added an example for "locno" in the mi interface
  - Added examples in the Break command manual.

RISC-V: Add 'Ssstateen' extension and its CSRs

This commit adds 'Ssstateen' extension, which is a supervisor-visible view
of the 'Smstateen' extension.  It means, this extension implements sstateen*
and hstateen* CSRs of the 'Smstateen' extension.

Note that 'Smstateen' extension itself is unchanged but due to
implementation simplicity, it is implemented so that 'Smstateen' implies
'Ssstateen' (just like 'M' implies 'Zmmul').

This is based on the latest version of RISC-V Profiles
(version 0.9-draft, Frozen):
<https://github.com/riscv/riscv-profiles/commit/226b7f643067b29abc6723fac60d5f6d3f9eb901>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Update implication rules.
(riscv_supported_std_s_ext) Add 'Ssstateen' extension.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Rename
CSR_CLASS_SMSTATEEN_AND_H{,_32} to CSR_CLASS_SSSTATEEN_...
Add CSR_CLASS_SSSTATEEN.
(riscv_csr_address): Support new/renamed CSR classes.
* testsuite/gas/riscv/csr.s: Add 'Ssstateen' extension to comment.
* testsuite/gas/riscv/csr-version-1p9p1.l: Reflect changes to
error messages.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/ssstateen-csr.s: Test for 'Ssstateen' CSRs.
* testsuite/gas/riscv/ssstateen-csr.d: Likewise.
* testsuite/gas/riscv/smstateen-csr-s.d: Test to make sure that
supervisor/hypervisor part of 'Smstateen' CSRs are accessible from
'RV32IH_Smstateen', not just from 'RV32IH_Ssstateen' that is tested
in ssstateen-csr.d.

include/ChangeLog:

* opcode/riscv-opc.h: Update DECLARE_CSR declarations with
new CSR classes.

Automatic date update in version.in

gdbserver/linux-x86: move lwp declaration out of __x86_64__ region

Commit 4855cbdc3d8f ("gdbserver/linux-x86: make is_64bit_tdesc accept
thread as a parameter") caused this when building in 32 bits / i386
mode:

      CXX    linux-x86-low.o
    In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope
      357 |     struct thread_info *thr = get_lwp_thread (lwp);
          |                                               ^~~
    /home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’
      709 | #define get_lwp_thread(lwp) ((lwp)->thread)
          |                               ^~~

This is because it moved the lwp variable declaration inside the
__x86_64__ guard, making it unavailable when building in 32 bits mode.
Move the lwp variable outside of the __x86_64__ region.

Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05

gdbserver: use current_process in ps_getpid

The following patch ("gdbserver: switch to right process in
find_one_thread") makes it so find_one_thread calls into libthread_db
with a current process but no current thread.  This tripped on ps_getpid
using current_thread in order to get the process' pid.  Get the pid from
`current_process ()` instead, which removes the need to have a current
thread.  Eventually, it would be good to get it from the
gdb_ps_prochandle_t structure, to avoid the need for a current process
as well.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I9d2fae266419199a2fbc2fde0a5104c6e0dbd2d5

gdbserver/linux-x86: make is_64bit_tdesc accept thread as a parameter

ps_get_thread_area receives as a parameter the lwpid it must work on.
It then calls is_64bit_tdesc, which uses the current_thread as the
thread to work on.  However, it is not said that both are the same.

This became a problem when working in a following patch that makes
find_one_thread switch to a process but to no thread (current_thread ==
nullptr).  When libthread_db needed to get the thread area,
is_64bit_tdesc would try to get the regcache of a nullptr thread.

Fix that by making is_64bit_tdesc accept the thread to work on as a
parameter.  Find the right thread from the context, when possible (when
we know the lwpid to work on).  Otherwise, pass "current_thread", to
retain the existing behavior.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007

gdbserver/linux: take condition out of callback in find_lwp_pid

Just a small optimization, it's not necessary to recompute lwp at each
iteration.

While at it, change the variable type to long, as ptid_t::lwp returns a
long.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105

Fix deletion of FinishBreakpoints

Currently, FinishBreakpoints are set at the return address of a frame based on
the `finish' command, and are meant to be temporary breakpoints. However, they
are not being cleaned up after use, as reported in PR python/18655. This was
happening because the disposition of the breakpoint was not being set
correctly.

This commit fixes this issue by correctly setting the disposition in the
post-stop hook of the breakpoint. It also adds a test to ensure this feature
isn't regressed in the future.

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

gdb: fix symtab.c build on 32 bit targets

When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get:

      CXX    symtab.o
    /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function â€˜std::vector<symbol_search> global_symbol_searcher::search() const’:
    /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: â€˜__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
     4961 |               sprintf (tmp, "operator%.*s%s", fix, " ", opname);
          |                                            ^
    In file included from /usr/include/stdio.h:894,
                     from ../gnulib/import/stdio.h:43,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86,
                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20:
    In function â€˜int sprintf(char*, const char*, ...)’,
        inlined from â€˜std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16:
    /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: â€˜__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647
       38 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       39 |                                   __glibc_objsize (__s), __fmt,
          |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       40 |                                   __va_arg_pack ());
          |                                   ~~~~~~~~~~~~~~~~~

PR build/29798 shows a similar error message but on Solaris.

Work around that by using string_printf.  It is a good thing to get rid
of the alloca anyway.

Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798

gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assembler

Convert the gdb.cp/call-method-register.exp test to make use of the
DWARF assembler.

The existing gdb.cp/call-method-register.exp test relies on a GCC
extension - forcing a local variable into a particular named register.

This means that the test will only work with Clang, and, as we have to
name the register into which the variable will be placed, will only
work for those targets where we've selected a suitable register,
currently this is x86-64, i386, and ppc64.

By switching to the DWARF assembler, the test will work with gcc and
clang, and should work on most, if not all, architectures.

The test creates a small structure, something that can fit within a
register, and then tries to call a method on the structure from within
GDB.  This should fail because GDB can't take the address of the in
register structure (for the `this` pointer).

As the test is for a failure case, then we don't really care _which_
register the structure is in, and I take advantage of this for the
DWARF assembler test, I just declare that the variable is in
DW_OP_reg0, whatever that might be.  I've tested the new test on
x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all
these architectures, which is already more than we used to cover.

Additionally, on x86-64, I've tested with Clang and gcc, and the test
runs and passed with both compilers.

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

gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with Clang

The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single
failure when run with some older versions of Clang, e.g. 9.0.1.

The problem appears to be with Clang's generated line table.  The test
source looks like this:

  int
  main()
  {
    asm ("main_label: .globl main_label");
    return 0;
  }

In GDB, when we 'start', we expect to stop at the 'return 0;' line.
This is the behaviour when the compiler is gcc, or later versions of
Clang.

However, with Clang 9.0.2, I see GDB stop on the 'asm' line.

In this commit I'll fix this issue by placing a breakpoint on the
return line, and then using gdb_continue_to_breakpoint to ensure we
have stopped in the correct place.

Of course, using gdb_continue_to_breakpoint will only work if we are
not already stopped at the breakpoint location, so I've added some
filler work before the 'return 0;' line.  With this done we can use
gdb_continue_to_breakpoint in all cases.

As a result of adding the new filler work, one of the later tests,
that used the 'list' command, no longer see the correct expected
output (the top line of the source file is no longer included in the
output).  I've fixed this by listing a known specific line, the test
is checking that GDB managed to find the source file, it doesn't
matter which source line we list, as long as we can list something.

gdb/testsuite: rename source file gdb.debuginfod/main.c

The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file
named main.c.  I can't see any particular reason why the file is named
as such.

Usually test source files are named after the test script.

This commit just renames the source file inline with the test script,
and updates the call to standard_testfile (removing the reference to
main.c).

There's no particular reason for this change other than seeing the
file named main.c made me thing that the source file must be shared
with some other test (it isn't).

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

gdb/testsuite: add (and use) a new build-id compile option

I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was
failing when run with Clang as the compiler.

This test relies on the compiled binaries having a build-id within
them.  For GCC, really GNU ld, the default is to always include a
build-id.

When compiling with Clang though, the default is for no build-id.

I did consider *always* turning on the build-id feature when the
compiler is Clang, but that felt a little weird.

Instead, I propose that we add a new 'build-id' compiler option to
gdb_compile, this flag indicates that the test _requires_ a build-id.
In gcc_compile we can then add the required flags if the compiler is
Clang so that we do get a build-id.

With this change the gdb.debuginfod/fetch_src_and_symbols.exp test
now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with
gcc.  The 'mostly' part is an unrelated issue, and will be addressed
in a later commit in this series.

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

gdb/testsuite: fix gdb.compile/compile-ops.exp with clang

I noticed that the gdb.compile/compile-ops.exp test was failing when
run with Clang as the compiler.

This test makes use of the DWARF assembler, and, it turns out, uses
a technique which is not portable to Clang.   This problem is
described in the comment on the function_range proc in lib/dwarf.exp,
the explanation is:

  # If the compiler is gcc, we can do the following to get function start
  # and end address too:
  #
  # asm ("func_start: .globl func_start");
  # static void func (void) {}
  # asm ("func_end: .globl func_end");
  #
  # however, this isn't portable, because other compilers, such as clang,
  # may not guarantee the order of global asms and function.  The code
  # becomes:
  #
  # asm ("func_start: .globl func_start");
  # asm ("func_end: .globl func_end");
  # static void func (void) {}

These start/end labels are used for computing the function start, end,
and length.  The portable solution is to place a label within the
function, like this:

  #  int main (void)
  #  {
  #    asm ("main_label: .globl main_label");
  #    return 0;
  #  }

And make use of 'proc function_range' (from lib/dwarf.exp).

So, that's what I do in this commit.

One consequence of this change is that we need to compile the source
file, and have it loaded into a GDB session, before calling
function_range, so I've added an early call to prepare_for_testing.

Additionally, this test script was generating the DWARF assembler into
a file called gdbjit-ops.S, I suspect a copy and paste issue there, so
I've switched this to use compile-ops-dbg.S instead, which is more
inline with what other DWARF assembler tests do.

The only other change, which might be a problem, is that I also
deleted these two lines from the source file:

  asm (".section \".text\"");
  asm (".balign 8");

These lines were setting the alignment of the .text section.  What I
don't know is whether this was significant or not.  If it is
significant, then I can't see why.

On x86-64, the test still passes fine without these lines, but that
doesn't mean the test wont start failing on some other architecture.

Still, I figure, lets remove them, then, if/when we find a test that
starts failing, we can add the lines back, along with an explanation
for why the extra alignment is required.

But, if people would prefer to be more conservative, then I'm happy to
just add the lines back.

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

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

I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was
failing when run with Clang.  Or rather, the test was not running as
the test executable failed to compile.

The problem is that Clang was emitting this warning:

  warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]

This warning is emitted when compiling the assembler file generated
by the DWARF assembler.

Most DWARF assembler tests generate the assembler file into a file
with the '.S' extension.  However, this particular test uses a '.s'
extension.

Now a .S file will be passed through the preprocessor, while a .s will
be sent straight to the assembler.  My guess is that Clang doesn't
support the -fdiagnostics-color=never option for the assembler, but
does for the preprocessor.

That's a little annoying, but easily worked around.  We don't care if
our assembler file is passed through the preprocessor, so, in this
commit, I just change the file extension from .s to .S, and the
problem is fixed.

Currently, the unavailable-dwarf-piece.exp script names the assembler
file using standard_output_file, in this commit I've switched to make
use of standard_testfile, as that seems to be the more common way of
doing this sort of thing.

With these changes the test now passes with Clang 9.0.1 and 15.0.2,
and also still passes with gcc.

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

gdb/testsuite: don't avoid DWARF assembler tests with Clang

Two tests make the claim that the DWARF assembler requires gcc,
however, this isn't true.  I think at one point, when the DWARF
assembler was first added, we did use some techniques that were not
portable (see the comments in lib/dwarf.exp on function_range for
details), however, I think most DWARF assembler tests will now work
fine with Clang.

The two tests that I modify in this commit both work fine with Clang,
at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any
problems, so I'm removing the early return logic that stops these
tests from running with Clang.

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

GAS fix alignment for aarch64-pe

Fixes issue where various values of '.align' causes writing of COFF files to fail.
Specific to the aarch64-pe target.

PR29799 heap buffer overflow in display_gdb_index dwarf.c:10548

PR 29799
* dwarf.c (display_gdb_index): Typo fix.

go32 sanity check

* coff-stgo32 (go32exe_check_format): Sanity check stubsize against
filesize before malloc.

Regen potfiles for sframe

Automatic date update in version.in

[gas, aarch64]: fix build breakage for aarch64-pe

SFrame is supported for ELF only.  Keep the definitions and declarations
guarded with OBJ_ELF consistently.

ChangeLog:

* gas/config/tc-aarch64.h:  Guard SFrame related definitions
  with OBJ_ELF.

Fix static initialization order problem in windows-nat.c

This patch fixes a static initialization order problem in
windows-nat.c that was pointed out by Jon Turney.  The underlying
problem is that the windows_nat_target constructor relies on
serial_logfile already being constructed, but this is not enforced by
C++ rules.  This patch fixes the problem by initializing the global
windows_nat_target later.

opcodes: Define NoSuf in i386-opc.tbl

Use NoSuf to replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf
and add the explicit NoSuf to AddrPrefixOpReg in templates.

* i386-opc.tbl (NoSuf): New macro.
(AddrPrefixOpReg): Remove No_?Suf.
Replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf with
NoSuf in templates.
Add NoSuf to AddrPrefixOpReg in templates.

i386: Move i386_seg_prefixes to gas

gas/

* config/tc-i386.c (i386_seg_prefixes): New. Moved from opcodes.

opcodes/

* i386-opc.c (i386_seg_prefixes): Removed.
* i386-opc.h (i386_seg_prefixes): Likewise.

PowerPC, fix gdb.base/retval-large-struct.exp

Support for printining non-trivial return values was recently added in
commit:

  commit a0eda3df5b750ae32576a9be092b361281a41787
  Author: Carl Love <cel@us.ibm.com>
  Date:   Mon Nov 14 16:22:37 2022 -0500

    PowerPC, fix support for printing the function return value for non-trivial values.

The functionality can now be used to fix gdb.base/retval-large-struct.exp.
The test just needs to be compiled with -fvar-tracking to enable GDB to
determine the address off the return buffer when the function is called.

The current output from the test:

34        return big_struct;
(gdb) PASS: gdb.base/retval-large-struct.exp: continue to breakpoint: Break in print_large_struct
finish
warning: Cannot determine the function return value.
Try compiling with -fvar-tracking.
Run till exit from #0  return_large_struct () at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:34
main (argc=1, argv=0x7fffffffcd58) at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:44
44        return 0;
Value returned has type: struct big_struct_t. Cannot determine contents
(gdb) FAIL: gdb.base/retval-large-struct.exp: finish from return_large_struct
testcase binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.exp completed in 1 seconds

This patch adds the command line argument -fvar-tracking to enable gdb to
determine the return vaule and thus fixing the test.

Patch tested on Power 10 with no regressions.

Use boolean literals for pagination_enabled

I noticed a couple of spots that used '0' rather than 'false' when
modifying pagination_enabled.  This patch cleans these up.

Change NULL to nullptr in gdb/infcmd.c and gdb/infrun.c

The GDB coding standard specifies that nullptr should be used instead of
NULL.  There are numerous uses of NULL and nullptr in files infcmd.c and
infrun.c.  This patch replaces the various uses of NULL with nullptr in
the source files.  The use of NULL in the comments was not changed.

The patch does not introduce any functional changes.

The patch has been tested on PowerPC and Intel X86_64 with no new unexpected
test failures, unresolved tests, new core files etc.

ld: Always call elf_backend_output_arch_local_syms

Always call elf_backend_output_arch_local_syms since only the backend
knows if elf_backend_output_arch_local_syms is needed when all symbols
are striped.  elf_backend_output_arch_local_syms is defined only for
x86, ARM and AARCH64.  On x86, elf_backend_output_arch_local_syms must
be called to handle local IFUNC symbols even if all symbols are striped.
Update ARM and AARCH64 to skip elf_backend_output_arch_local_syms when
symbols aren't needed.

bfd/

PR ld/29797
* elf32-arm.c (elf32_arm_output_arch_local_syms): Skip if symbols
aren't needed.
* elfnn-aarch64.c (elfNN_aarch64_output_arch_local_syms):
Likewise.
* elflink.c (bfd_elf_final_link): Always call
elf_backend_output_arch_local_syms if available.

ld/

PR ld/29797
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29797 test.
* testsuite/ld-elf/pr29797.c: New file.

gdb: new $_inferior_thread_count convenience variable

Add a new convenience variable $_inferior_thread_count that contains
the number of live (non-exited) threads in the current inferior.  This
can be used in command scripts, or breakpoint conditions, etc to
adjust the behaviour for multi-threaded inferiors.

This value is only stable in all-stop mode.  In non-stop mode, where
new threads can be started, and existing threads exit, at any time,
this convenience variable can give a different value each time it is
evaluated.

Remove two obsolete declarations

I happened to find a couple of obsolete declarations in cli-interp.h.
This patch removes them.  Tested by rebuilding.

gdb/testsuite: fix failure in gdb.python/py-send-packet.exp

While working on another patch I noticed that, when run on an AArch64
target, the test gdb.python/py-send-packet.exp was failing:

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
  line 106, in run_auxv_send_packet_test
      assert string == expected_result
  AssertionError
  Error while executing Python code.
  (gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function

The test uses 'maint packet ...' to send a packet to gdbserver, and
then captures the output in TCL.  This output is then passed through
to a Python function, which performs some actions using the Python
API, and compares the results from the Python API to the results
captured in TCL from 'maint packet ...'.

The problem is that the output captured in TCL contains lots of things
like '\x000', when this is passed through to Python the '\x' causes
this to be treated as an escape code, which isn't what we want - we
want the actual string "\x000".

So, in the TCL part of the test we were expanding '\x' to '\\x', this
seemed to work fine for my testing on x86-64.

However, on AArch64 what I see is that the results from 'maint packet
...' contain a literal '\' character followed by a literal 'x'
character.  When GDB prints this in the 'maint packet' output, GDB
escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.

However, now our TCL test script kicks in and tries to "fix" the '\x',
this means we now have '\\\x', which isn't correct.

The problem is that in the TCL script we are too restrictive, we
expand '\x' to '\\x', but really, we should be expanding all '\'
characters, regardless of what follows them.  This is what this patch
does.

After this the gdb.python/py-send-packet.exp test passes on AArch64
for me.

Fix call functions command bug in 64 bits programs for AIX

In AIX for 64 bit programs we need to zero extend variables
of integer or enum or char data type.

Otherwise a zero will get dumped in the register as we memset
our word to 0 and we copy non zero extended contents to the cache.

gdb/fortran/testsuite: print values and types of string variables

While looking through the Fortran tests, I couldn't find a test of GDB
printing the value and type of a Fortran string defined using the
'character*SIZE' notation.

This works fine in GDB right now, but I thought it wouldn't hurt to
have a test for this, so this commit adds such a test.

The test also includes printing a string that includes some embedded
special characters: \n \r \t \000 - that's right, as Fortran strings
are stored as an address and length, it is fine to include an embedded
null, so this test includes an example of that.

Standard Fortran doesn't support backslash escape sequences within
strings, the special characters must be generated using the `achar`
function.  However, when GDB prints the strings we currently print
using the standard C like backslash sequences.

I'm not currently proposing to change that behaviour, the backslash
sequences are more compact than the standard Fortran way of doing
things, and are so widely used that I suspect most Fortran programmers
will understand them.

Fix various procfs.c compilation errors

procfs.c has accumulated several compilation errors lately (some of them
new with GCC 12), which are fixed by this patch:

* auxv_parse gets:

/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error: \91int
procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)\92
marked \91override\92, but does not override
  144 |   int auxv_parse (gdb_byte **readptr,
      |       ^~~~~~~~~~

  Obviouly, procfs.c was missed in the auxv_parse constification.

* dead_procinfo has:

/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function \91void
dead_procinfo(procinfo*, const char*, int)\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address
of \91procinfo::pathname\92 will never be NULL [-Waddress]
  563 |   if (pi->pathname)
      |       ~~~~^~~~~~~~
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note:
\91procinfo::pathname\92 declared here
  238 |   char pathname[MAX_PROC_NAME_SIZE];    /* Pathname to /proc entry */
      |        ^~~~~~~~

  The warning is correct, so the code can lose support for the NULL
  pathname case.

* create_inferior has this ugly warning:

/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function \91virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: \91char* std::strncpy(char*, const char*, size_t)\92 output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
 2815 |           strncpy (tryname, p, len);
      |           ~~~~~~~~^~~~~~~~~~~~~~~~~
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed here
 2814 |             len = strlen (p);
      |                   ~~~~~~~^~~

  It seems that this is another case of GCC PR middle-end/88059, which
  Martin Sebor refuses to fix.  So I'm using the hack suggested in the
  PR to use memcpy instead of strncpy.

* find_memory_regions_callback fails with

/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function \91int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)\92:
/vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few arguments to function
 3167 |   return (*func) ((CORE_ADDR) map->pr_vaddr,
      |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
 3168 |                   map->pr_size,
      |                   ~~~~~~~~~~~~~
 3169 |                   (map->pr_mflags & MA_READ) != 0,
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 3170 |                   (map->pr_mflags & MA_WRITE) != 0,
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 3171 |                   (map->pr_mflags & MA_EXEC) != 0,
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 3172 |                   1, /* MODIFIED is unknown, pass it as true.  */
      |                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 3173 |                   data);
      |                   ~~~~~

  Again, procfs.c was overlooked when adding the new memory_tagged arg.
  Unfortunately, it wasn't even documented in gdb/defs.h when it was
  added in

commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
Author: Luis Machado <luis.machado@arm.com>
Date:   Thu Mar 31 11:42:35 2022 +0100

    [AArch64] MTE corefile support

With those changes, procfs.c compiles again.  Together with the hack
from the Solaris gdbsupport breakage reported in PR build/29791, I was
able to build and test gdb on both amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11.

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

RISC-V: Add T-Head Int vendor extension

This patch adds the XTheadInt extension, which provides interrupt
stack management instructions.

The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
  https://github.com/riscv-non-isa/riscv-toolchain-conventions

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head Fmv vendor extension

This patch adds the XTheadFmv extension, which allows to access the
upper 32 bits of a double-precision floating-point register in RV32.

The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
  https://github.com/riscv-non-isa/riscv-toolchain-conventions

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

[gdb/testsuite] Fix DUPLICATE in gdb.arch/ppc-fp.exp

I noticed:
...
DUPLICATE: gdb.arch/ppc-fp.exp: next
...

Fix this by adding unique test names.

Tested on powerpc64le-linux.

Automatic date update in version.in

Add myself to the gdb/MAINTAINERS write-after-approval list

Guard against frame.c destructors running before frame-info.c's

On x86_64-windows, since 04e2ac7b2a7, we observe this internal error:

  [...]/gdbsupport/intrusive_list.h:458: internal-error: erase_element:
  Assertion `elem_node->prev != INTRUSIVE_LIST_UNLINKED_VALUE' failed.

Breaking in the destructors for intrusive_list and frame_info_ptr shows that
in this configuration, the destructors for frame.c's statically-stored
objects are run before frame-info.c's:

  Thread 1 hit Breakpoint 7, intrusive_list<frame_info_ptr,
  intrusive_base_node<frame_info_ptr> >::~intrusive_list (this=0x7ff69c418c90
  <frame_info_ptr::frame_list>, __in_chrg=<optimized out>)
  [...]/../gdbsupport/intrusive_list.h:250
  250     clear ();
  (gdb) bt
  #0  intrusive_list<frame_info_ptr, intrusive_base_node<frame_info_ptr> >
      ::~intrusive_list (this=0x7ff69c418c90 <frame_info_ptr::frame_list>,
      __in_chrg=<optimized out>) [...]/../gdbsupport/intrusive_list.h:250
  #1  0x00007ff69b78edba in __tcf_1 () [...]/frame-info.c:27
  #2  0x00007ff9c457aa9f in msvcrt!_initterm_e ()
      from C:\Windows\System32\msvcrt.dll
  #3  0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
      [...]/main.c:1111
  #4  0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
  #5  0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
  #6  0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32
  (gdb) c
  Continuing.

  Thread 1 hit Breakpoint 8, frame_info_ptr::~frame_info_ptr
  (this=0x7ff69c418e20 <selected_frame>, __in_chrg=<optimized out>)
  [...]/frame-info.h:74
  74     if (is_linked ())
  (gdb) bt
  #0  frame_info_ptr::~frame_info_ptr (this=0x7ff69c418e20 <selected_frame>,
      __in_chrg=<optimized out>) [...]/frame-info.h:74
  #1  0x00007ff69b79a643 in __tcf_1 () [...]/frame.c:1675
  #2  0x00007ff9c457aa9f in msvcrt!_initterm_e () from
      C:\Windows\System32\msvcrt.dll
  #3  0x00007ff69b8246a6 in captured_main_1 (context=0x5ffe00)
      [...]/main.c:1111
  #4  0x00007ff69b825149 in captured_main (data=0x5ffe00) [...]/main.c:1320
  #5  0x00007ff69b8251b1 in gdb_main (args=0x5ffe00) [...]/main.c:1345
  #6  0x00007ff69b5d1730 in main (argc=2, argv=0x751730) [...]/gdb.c:32

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

PR29788, gprofng cannot display Java's generated assembly code

gprofng/ChangeLog
2022-11-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29788
* src/Experiment.h: Declare dyntext_name.
* src/Experiment.cc: Use dyntext_name to initialize img_fname.

[gdb/testsuite] Use gdb_gcore_cmd in gdb.threads/gcore-thread.exp

I noticed a plain gcore command in test-case gdb.threads/gcore-thread.exp:
...
    gdb_test "gcore $core0file" "Saved corefile .*" \
      "save a zeroed-threads corefile"
...

Use gdb_gcore_cmd instead.

Tested on x86_64-linux.

Bug fix in commit for printing the function return value for non-trivial values

The recent commit:

  commit a0eda3df5b750ae32576a9be092b361281a41787
  Author: Carl Love <cel@us.ibm.com>
  Date:   Mon Nov 14 16:22:37 2022 -0500

    PowerPC, fix support for printing the function return value for non-trivial values.

Is generating a segmentation fault on x86_64-linux.

  segfault:
  ...
  PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
  ERROR: GDB process no longer exists
  UNRESOLVED: gdb.asm/asm-source.exp: finish from foo3
  ...

  Reproduced on command line:
  ...
  $ gdb -q -batch -x outputs/gdb.asm/asm-source/gdb.in.1
  ...

  The problem seems to be that:
  ...
  Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
  0x000000000043de7a in symbol::type (this=0x0) at
  .../gdb_versions/devel/src/gdb/symtab.h:1287
  1287        return m_type;
  ...
  because:
  ...
  (gdb) up
  #1  0x0000000000852d94 in finish_command (arg=0x0, from_tty=0)
     at .../gdb_versions/devel/src/gdb/infcmd.c:1887
  1887        = check_typedef (sm->function->type ()->target_type ());
  (gdb) p sm->function
  $1 = (symbol *) 0x0

The code is not checking if sm->function is NULL.  If sm->function is NULL
the check for the return buffer should be skipped.

Update Ada tasks documentation

My co-worker Kévin noticed that the Ada tasks documentation is
slightly out of date -- it does not document all the states that can
be reported by ada-tasks.c.

This patch adds the missing states to the appropriate node, and
updates one state to reflect a change made some time ago.

gdb: add "set style tui-current-position on|off", default to off

As discussed at:

 https://sourceware.org/pipermail/gdb-patches/2020-June/169519.html

this patch disables source and assembly code highlighting for the
text highlighted by the TUI's current position indicator, and adds a
command to enable it back.

[gdb/testsuite] Modernize gdb.arch/i386-biarch-core.exp

I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the
completion limit for "complete set gnutarget":
...
set gnutarget vms-libtxt^M
set gnutarget  *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget
...

Fix this by using get_set_option_choices.

Also use get_set_option_choices for "complete set architecture i386", which
required extending get_set_option_choices to accept a second argument, such
that we can do:
...
set archs [get_set_option_choices "set architecture" "i386"]
...
because this returns an empty list:
...
set archs [get_set_option_choices "set architecture i386"]
...
because it does "complete set architecture i386 ".

Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.arch/ppc64-symtab-cordic.exp without bzip2

After de-installing bzip2, I run into:
...
Running ppc64-symtab-cordic.exp ...
sh: bzip2: command not found
PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \
  src/gdb/testsuite/gdb.arch/cordic.ko.bz2
...

Fix these by:
- using remote_exec instead of catch system, and
- using file tail in the untested message.

I've tried making output redirection work with remote_exec, but that seems to
be broken, so we now:
- copy the file $f.bz2 into the desired location $dir/$f.bz2, and
- decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file
  $dir/$f.

Factor out new function decompress_bz2 to make the test-case less verbose, and
also use it in gdb.arch/i386-biarch-core.exp.

Tested on x86_64-linux, without and with bzip2 installed.

Automatic date update in version.in

doc: add SFrame spec file

ChangeLog:

* libsframe/Makefile.am: Add info-in-builddir to
  AUTOMAKE_OPTIONS. Include doc/local.mk.
* libsframe/Makefile.in: Regenerated.
* libsframe/configure: Likewise.
* libsframe/configure.ac: Check for makeinfo and set BUILD_INFO.
* libsframe/doc/local.mk: New file.
* libsframe/doc/sframe-spec.texi: Likewise.

gas/NEWS: add text about new command line option and SFrame support

ChangeLog:

* gas/NEWS: Add SFrame related news.

binutils/NEWS: add text for SFrame support

ChangeLog:

* binutils/NEWS: Add item for SFrame support.

src-release.sh: Add libsframe

Add libsframe to the list of top level directories that will be included
in a release.

ChangeLog:

* src-release.sh: Add libsframe

readelf/objdump: support for SFrame section

This patch adds support for SFrame in readelf and objdump. The arguments
of --sframe are optional for both readelf and objdump.

include/ChangeLog:

* sframe-api.h (dump_sframe): New function declaration.

ChangeLog:

* binutils/Makefile.am: Add dependency on libsframe for
readelf and objdump.
* binutils/Makefile.in: Regenerate.
* binutils/doc/binutils.texi: Document --sframe=[section].
* binutils/doc/sframe.options.texi: New file.
* binutils/objdump.c: Add support for SFrame format.
* binutils/readelf.c: Likewise.
* include/sframe-api.h: Add new API for dumping .sframe
section.
* libsframe/Makefile.am: Add sframe-dump.c.
* libsframe/Makefile.in: Regenerate.
* libsframe/sframe-dump.c: New file.

bfd: linker: merge .sframe sections

The linker merges all the input .sframe sections.  When merging, the
linker verifies that all the input .sframe sections have the same
abi/arch.

The linker uses libsframe library to perform key actions on the
.sframe sections - decode, read, and create output data.  This
implies buildsystem changes to make and install libsframe before
libbfd.

The linker places the output .sframe section in a new segment of its
own: PT_GNU_SFRAME.  A new segment is not added, however, if the
generated .sframe section is empty.

When a section is discarded from the final link, the corresponding
entries in the .sframe section for those functions are also deleted.

The linker sorts the SFrame FDEs on start address by default and sets
the SFRAME_F_FDE_SORTED flag in the .sframe section.

This patch also adds support for generation of SFrame unwind
information for the .plt* sections on x86_64.  SFrame unwind info is
generated for IBT enabled PLT, lazy/non-lazy PLT.

The existing linker option --no-ld-generated-unwind-info has been
adapted to include the control of whether .sframe unwind information
will be generated for the linker generated sections like PLT.

Changes to the linker script have been made as necessary.

ChangeLog:

* Makefile.def: Add install dependency on libsframe for libbfd.
* Makefile.in: Regenerated.
* bfd/Makefile.am: Add elf-sframe.c
* bfd/Makefile.in: Regenerated.
* bfd/bfd-in2.h (SEC_INFO_TYPE_SFRAME): Regenerated.
* bfd/configure: Regenerate.
* bfd/configure.ac: Add elf-sframe.lo.
* bfd/elf-bfd.h (struct sframe_func_bfdinfo): New struct.
(struct sframe_dec_info): Likewise.
(struct sframe_enc_info): Likewise.
(struct elf_link_hash_table): New member for encoded .sframe
object.
(struct output_elf_obj_tdata): New member.
(elf_sframe): New access macro.
(_bfd_elf_set_section_sframe): New declaration.
* bfd/elf.c (get_segment_type): Handle new segment
PT_GNU_SFRAME.
(bfd_section_from_phdr): Likewise.
(get_program_header_size): Likewise.
(_bfd_elf_map_sections_to_segments): Likewise.
* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): Add
contents to the .sframe sections or .plt* entries.
* bfd/elflink.c (elf_section_ignore_discarded_relocs): Handle
SEC_INFO_TYPE_SFRAME.
(_bfd_elf_default_action_discarded): Handle .sframe section.
(elf_link_input_bfd): Merge .sframe section.
(bfd_elf_final_link): Write the output .sframe section.
(bfd_elf_discard_info): Handle discarding .sframe section.
* bfd/elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Create
.sframe section for .plt and .plt.sec.
(_bfd_x86_elf_finish_dynamic_sections): Handle .sframe from
.plt* sections.
* bfd/elfxx-x86.h (PLT_SFRAME_FDE_START_OFFSET): New
definition.
(SFRAME_PLT0_MAX_NUM_FRES): Likewise.
(SFRAME_PLTN_MAX_NUM_FRES): Likewise.
(struct elf_x86_sframe_plt): New structure.
(struct elf_x86_link_hash_table): New member.
(struct elf_x86_init_table): New members for .sframe
creation.
* bfd/section.c: Add new definition SEC_INFO_TYPE_SFRAME.
* binutils/readelf.c (get_segment_type): Handle new segment
PT_GNU_SFRAME.
* ld/ld.texi: Update documentation for
--no-ld-generated-unwind-info.
* ld/scripttempl/elf.sc: Support .sframe sections.
* ld/Makefile.am (TESTSFRAMELIB): Use it.
(check-DEJAGNU): Likewise.
* ld/Makefile.in: Regenerated.
* ld/configure.ac (TESTSFRAMELIB): Set to the .so or .a like TESTBFDLIB.
* ld/configure: Regenerated.
* bfd/elf-sframe.c: New file.

include/ChangeLog:

* elf/common.h (PT_GNU_SFRAME): New definition.
* elf/internal.h (struct elf_segment_map): Handle new segment
type PT_GNU_SFRAME.

ld/testsuite/ChangeLog:

* ld/testsuite/ld-bootstrap/bootstrap.exp: Add SFRAMELIB.
* ld/testsuite/ld-aarch64/aarch64-elf.exp: Add new test
  sframe-simple-1.
* ld/testsuite/ld-aarch64/sframe-bar.s: New file.
* ld/testsuite/ld-aarch64/sframe-foo.s: Likewise.
* ld/testsuite/ld-aarch64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-sframe/sframe-empty.d: New test.
* ld/testsuite/ld-sframe/sframe-empty.s: New file.
* ld/testsuite/ld-sframe/sframe.exp: New testsuite.
* ld/testsuite/ld-x86-64/sframe-bar.s: New file.
* ld/testsuite/ld-x86-64/sframe-foo.s: Likewise.
* ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-x86-64/sframe-plt-1.d: Likewise.
* ld/testsuite/ld-x86-64/sframe-simple-1.d: Likewise.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests -
  sframe-simple-1, sframe-plt-1.
* ld/testsuite/lib/ld-lib.exp: Add new proc to check if
  assembler supports SFrame section.
* ld/testsuite/ld-sframe/discard.d: New file.
* ld/testsuite/ld-sframe/discard.ld: Likewise.
* ld/testsuite/ld-sframe/discard.s: Likewise.

libsframe: add the SFrame library

libsframe is a library that allows you to:
- decode a .sframe section
- probe and inspect a .sframe section
- encode (and eventually write) a .sframe section.

This library is currently being used by the linker, readelf, objdump.
This library will also be used by the SFrame unwinder which is still
to be upstream'd.

The file include/sframe-api.h defines the user-facing APIs for decoding,
encoding and probing .sframe sections. A set of error codes together
with their error message strings are also defined.

Endian flipping is performed automatically at read and write time, if
cross-endianness is detected.

ChangeLog:

* Makefile.def: Add libsframe as new module with its
dependencies.
* Makefile.in: Regenerated.
* binutils/Makefile.am: Add libsframe.
* binutils/Makefile.in: Regenerated.
* configure: Regenerated
* configure.ac: Add libsframe to host_libs.
* libsframe/Makefile.am: New file.
* libsframe/Makefile.in: New file.
* libsframe/aclocal.m4: New file.
* libsframe/config.h.in: New file.
* libsframe/configure: New file.
* libsframe/configure.ac: New file.
* libsframe/sframe-error.c: New file.
* libsframe/sframe-impl.h: New file.
* libsframe/sframe.c: New file.

include/ChangeLog:

* sframe-api.h: New file.

testsuite/ChangeLog:

* libsframe/testsuite/Makefile.am: New file.
* libsframe/testsuite/Makefile.in: Regenerated.
* libsframe/testsuite/libsframe.decode/Makefile.am: New
  file.
* libsframe/testsuite/libsframe.decode/Makefile.in:
  Regenerated.
* libsframe/testsuite/libsframe.decode/decode.exp: New file.
* libsframe/testsuite/libsframe.encode/Makefile.am:
  Likewise.
* libsframe/testsuite/libsframe.encode/Makefile.in:
  Regenerated.
* libsframe/testsuite/libsframe.encode/encode.exp: New file.
* libsframe/testsuite/libsframe.encode/encode-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/be-flipping.c: Likewise.
* libsframe/testsuite/libsframe.decode/frecnt-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/frecnt-2.c: Likewise.
* libsframe/testsuite/libsframe.decode/DATA-BE: New file.
* libsframe/testsuite/libsframe.decode/DATA1: Likewise.
* libsframe/testsuite/libsframe.decode/DATA2: Likewise.

gas: testsuite: add new tests for SFrame unwind info

Earlier these tests were in the same commit as previous which adds the
support in GNU assembler to generate .sframe section from CFI
directives.  Splitting this out here for ease of applying and testing.

ChangeLog:

* gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.d: New file.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-aarch64-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-2.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-3.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-4.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-5.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-6.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-7.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-common-8.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe-x86_64-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-1.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-1.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-2.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-3.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-3.s: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-4.d: Likewise.
* gas/testsuite/gas/cfi-sframe/common-empty-4.s: Likewise.

gas: generate .sframe from CFI directives

Currently supported for x86_64 and aarch64 only.

[PS: Currently, the compiler has not been adapted to generate
".cfi_sections" with ".sframe" in it.  The newly added command line
option of --gsframe provides an easy way to try out .sframe support
in the toolchain.]

gas interprets the CFI directives to generate DWARF-based .eh_frame
info.  These internal DWARF structures are now consumed by
gen-sframe.[ch] sub-system to, in turn, create the SFrame unwind
information.  These internal DWARF structures are read-only for the
purpose of SFrame unwind info generation.

SFrame unwind info generation does not impact .eh_frame unwind info
generation.  Both .eh_frame and .sframe can co-exist in an ELF file,
if so desired by the user.

Recall that SFrame unwind information only contains the minimal
necessary information to generate backtraces and does not provide
information to recover all callee-saved registers.  The reason being
that callee-saved registers other than FP are not needed for stack
unwinding, and hence are not included in the .sframe section.

Consequently, gen-sframe.[ch] only needs to interpret a subset of
DWARF opcodes in gas.  More details follow.

[Set 1, Interpreted] The following opcodes are interpreted:
- DW_CFA_advance_loc
- DW_CFA_def_cfa
- DW_CFA_def_cfa_register
- DW_CFA_def_cfa_offset
- DW_CFA_offset
- DW_CFA_remember_state
- DW_CFA_restore_state
- DW_CFA_restore

[Set 2, Bypassed] The following opcodes are acknowledged but are not
necessary for generating SFrame unwind info:
- DW_CFA_undefined
- DW_CFA_same_value

Anything else apart from the two above-mentioned sets is skipped
altogether.  This means that any function containing a CFI directive not
in Set 1 or Set 2 above, will not have any SFrame unwind information
generated for them.  Holes in instructions covered by FREs of a single
FDE are not representable in the SFrame unwind format.

As few examples, following opcodes are not processed for .sframe
generation, and are skipped:
- .cfi_personality*
- .cfi_*lsda
- .cfi_escape
- .cfi_negate_ra_state
- ...

Not processing .cfi_escape, .cfi_negate_ra_state will cause SFrame
unwind information to be absent for SFrame FDEs that contain these CFI
directives, hence affecting the asynchronicity.

x86-64 and aarch64 backends need to have a few new definitions and
functions for .sframe generation.  These provide gas with architecture
specific information like the SP/FP/RA register numbers and an
SFrame-specific ABI marker.

Lastly, the patch also implements an optimization for size, where
specific fragments containing SFrame FRE start address and SFrame FDE
function are fixed up.  This is similar to other similar optimizations
in gas, where fragments are sized and fixed up when the associated
symbols can be resolved.  This optimization is controlled by a #define
SFRAME_FRE_TYPE_SELECTION_OPT and should be easy to turn off if needed.
The optimization is on by default for both x86_64 and aarch64.

ChangeLog:

* gas/Makefile.am: Include gen-sframe.c and sframe-opt.c.
* gas/Makefile.in: Regenerated.
* gas/as.h (enum _relax_state): Add new state rs_sframe.
(sframe_estimate_size_before_relax): New function.
(sframe_relax_frag): Likewise.
(sframe_convert_frag): Likewise.
* gas/config/tc-aarch64.c (aarch64_support_sframe_p): New
definition.
(aarch64_sframe_ra_tracking_p): Likewise.
(aarch64_sframe_cfa_ra_offset): Likewise.
(aarch64_sframe_get_abi_arch): Likewise.
(md_begin): Set values of sp/fp/ra registers.
* gas/config/tc-aarch64.h (aarch64_support_sframe_p): New
declaration.
(support_sframe_p): Likewise.
(SFRAME_CFA_SP_REG): Likewise.
(SFRAME_CFA_FP_REG): Likewise.
(SFRAME_CFA_RA_REG): Likewise.
(aarch64_sframe_ra_tracking_p): Likewise.
(sframe_ra_tracking_p): Likewise.
(aarch64_sframe_cfa_ra_offset): Likewise.
(sframe_cfa_ra_offset): Likewise.
(aarch64_sframe_get_abi_arch): Likewise.
(sframe_get_abi_arch): Likewise.
* gas/config/tc-i386.c (x86_support_sframe_p): New definition.
(x86_sframe_ra_tracking_p): Likewise.
(x86_sframe_cfa_ra_offset): Likewise.
(x86_sframe_get_abi_arch): Likewise.
* gas/config/tc-i386.h (x86_support_sframe_p): New declaration.
(support_sframe_p): Likewise.
(SFRAME_CFA_SP_REG): Likewise.
(SFRAME_CFA_FP_REG): Likewise.
(x86_sframe_ra_tracking_p): Likewise.
(sframe_ra_tracking_p): Likewise.
(x86_sframe_cfa_ra_offset): Likewise.
(sframe_cfa_ra_offset): Likewise.
(x86_sframe_get_abi_arch): Likewise.
(sframe_get_abi_arch): Likewise.
* gas/config/tc-xtensa.c (unrelaxed_frag_max_size): Add case for
rs_sframe.
* gas/doc/as.texi: Add .sframe to the documentation for
.cfi_sections.
* gas/dw2gencfi.c (cfi_finish): Create a .sframe section.
* gas/dw2gencfi.h (CFI_EMIT_sframe): New definition.
* gas/write.c (cvt_frag_to_fill): Handle rs_sframe.
(relax_segment): Likewise.
* gas/gen-sframe.c: New file.
* gas/gen-sframe.h: New file.
* gas/sframe-opt.c: New file.

gas: add new command line option --gsframe

When --gsframe is specified, the assembler will generate a .sframe
section from the CFI directives in the assembly.

ChangeLog:

* gas/as.c (parse_args): Parse args and set flag_gen_sframe.
* gas/as.h: Introduce skeleton for --gsframe.
* gas/doc/as.texi: document --gsframe.

sframe.h: Add SFrame format definition

The header sframe.h defines the SFrame format.

The SFrame format is the Simple Frame format.  It can be used to
represent the minimal necessary unwind information required for
backtracing.  The current version supports AMD64 and AARCH64.

More details of the SFrame format are included in the documentation
of the header file in this patch.

include/ChangeLog:
* sframe.h: New file.

Re: [gas] arm: Add support for new unwinder directive ".pacspval".

* testsuite/gas/arm/ehabi-pacbti-m.d: Limit test to ELF.

aarch64-pe can't fill 16 bytes in section .text

Without commit b66e671854, this:
 .p2align 4
 nop
 .p2align 3
 nop
results in an error when coff_frob_section attempts to pad out the
section to a 16-byte boundary.  Due to miscalculating the pad pattern
repeat count, write.c:write_contents attempts to shove 16 bytes of
padding into the remaining 4 bytes of the .text section.

* config/obj-coff.c (coff_frob_section): Correct fill count.
Don't pad after errors.

gdb/configure: regenerate

The commit bbaabc767a4293492817a0840819aef2768cce90 introduced an
incorrect thunk for the `configure' script.  This patch regenerates
configure by calling autoreconf.

gdb: use libtool in GDB_AC_CHECK_BFD

The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the
AC_LINK_IFELSE autoconf macro in order to link a simple program to
check features of libbfd.

If libbfd's link dependencies change, it was necessary to reflect them
either in the definition of the macro, or as a consequence of checking
for them with an autoconf macro resulting in an addition to LIBS.

This patch modifies the definition of the GDB_CHECK_BFD macro in order
to use libtool to perform the test link.  This makes it possible to
not have to list dependencies of libbfd (which are indirect to GDB) at
all.

After this patch:

  configure:28553: checking for ELF support in BFD
  configure:28573: ./libtool --quiet --mode=link gcc -o conftest \
                   -I../../gdb/../include -I../bfd \
                   -I../../gdb/../bfd -g -O2 \
                   -L../bfd -L../libiberty conftest.c -lbfd -liberty \
                   -lncursesw -lm -ldl  >&5
  configure:28573: $? = 0
  configure:28583: result: yes

Tests performed:

- Configure --with-system-zlib and --without-system-zlib.
- Check link dependencies of installed GDB with both --enable-shared
  and --disable-shared.
- Run installed GDB in both cases.

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

Fix crash in ada_print_type

The "varstring" paramter to ada_print_type can be null, but one spot
failed to check this.  This could cause a crash in some situations.

As this is Ada-specific, and we've been using it internally at AdaCore
for a while, I am going to push it.

Add AMD znver4 processor support

2022-09-28  Tejas Joshi <TejasSanjay.Joshi@amd.com>

gas/

        * config/tc-i386.c (cpu_arch): Add znver4 ARCH and rmpquery SUBARCH.
        (md_assemble): Expand comment before swap_operands() with rmpquery.
        * doc/c-i386.texi: Add znver4.
        * testsuite/gas/i386/arch-14-1.d: New.
        * testsuite/gas/i386/arch-14-1.s: New.
        * testsuite/gas/i386/arch-14-znver4.d: New.
        * testsuite/gas/i386/i386.exp: Add new znver4 test cases.
        * testsuite/gas/i386/rmpquery.d: New.
        * testsuite/gas/i386/rmpquery.s: New.
        * testsuite/gas/i386/x86-64-arch-4-1.d: New.
        * testsuite/gas/i386/x86-64-arch-4-1.s: New.
        * testsuite/gas/i386/x86-64-arch-4-znver4.d: New.

opcodes/

        * i386-dis.c (x86_64_table): Add rmpquery.
        * i386-gen.c (cpu_flag_init): Add CPU_ZNVER4_FLAGS and
        CPU_RMPQUERY_FLAGS.
        (cpu_flags): Add CpuRMPQUERY.
        * i386-opc.h (enum): Add CpuRMPQUERY.
        (i386_cpu_flags): Add cpurmpquery.
        * i386-opc.tbl: Add rmpquery insn.
        * i386-init.h: Re-generated.
        * i386-tbl.h: Re-generated.

gdb/testsuite: get_set_option_choices: expect \r\n after each item

I get some random failures since commit 8d45c3a82a0e ("[gdb/testsuite]
Set completions to unlimited in get_set_option_choices"), which can be
reproduced with:

    $ make check-read1 TESTS="gdb.base/parse_number.exp"

For instance:

    set architecture A^M
    Ambiguous item "A".^M
    (gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A

The problem is the regexp in get_set_option_choices, it is possible that
is only matches part of a completion result.  With check-read1, that is
always one letter.

Fix this by expecting the \r\n at the end of the line, so we only match
entire results.  Use ^ in match patterns to ensure we don't miss any
output.

Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: Ib1733737feab7dde0f7095866e089081a891054e

aarch64, testsuite: Fixed recently added cssc.d

Fixed wrong paste in cssc.d.

gas/ChangeLog:

* testsuite/gas/aarch64/cssc.d: Removed duplicate head.

[gdb/testsuite] Normalize gdbserver path name

Currently for the target board remote-gdbserver-on-localhost we use the
gdbserver file on build, using a file name which includes "/../".

Fix this by using a normalized file name instead.

This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
-    remote_exec build "chmod go-rx $objdir/outputs"
+    remote_exec build "chmod go-rx $objdir"
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target

With test-case gdb.base/jit-elf-so.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by:
- setting jit_libname with the name as returned by gdb_load_shlib
- allowing the libraries to be prefixed with the remote target directory.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target

With test-case gdb.base/jit-reader-exec.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix this by adding the missing gdb_remote_download.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/info-shared.exp for remote target

With test-case gdb.base/info-shared.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target

When running test-case gdb.base/solib-vanish.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target

When running test-case gdb.base/infcall-exec.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into:
...
(gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \
  "$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M
$1 = -1^M
(gdb) FAIL: gdb.base/infcall-exec.exp: call execlp
...

Fix this by using just:
...
(gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M
...
and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2
if it's available alongside.

Also fix the exec name in the test-case, such that we can successfully
run the test-case:
...
$ ./outputs/gdb.base/infcall-exec/infcall-exec
PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec'
$
...

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target

When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by using the name of a shared lib as returned by gdb_load_shlib.

This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
    set dest [gdb_download_shlib $file]
    gdb_locate_shlib $file
    return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

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

As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.

So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?

The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.

For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ...  -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
  print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...

Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.

We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.

And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
   ...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
  version_id_main=0: continue to STOP marker
...

Tested on x86_64-linux.

Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target

With test-case gdb.base/info_sources_2.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target

When running test-case gdb.base/foll-exec.exp with target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint
continue^M
Continuing.^M
[Inferior 1 (process 4476) exited normally]^M
(gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\
xited)
...

The problem is that the foll-exec executable expects the exec-ed executable
execd-prog alongside it, but it's missing.

Fix this by adding the missing gdb_remote_download.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml support

On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
  compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...

The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
    # If GDB is lack of XML support, and targets, like arm, have
    # multiple target descriptions, GDB doesn't know which target
    # description GDBserver uses, and may fail to parse 'g' packet
    # after connection.
    if { [gdb_skip_xml_test]
 && ([istarget "arm*-*-linux*"]
      || [istarget "mips*-*-linux*"]
      || [istarget "powerpc*-*-linux*"]
      || [istarget "s390*-*-linux*"]
      || [istarget "x86_64-*-linux*"]
      || [istarget "i\[34567\]86-*-linux*"]) } {
return 1
    }
...
but it doesn't trigger because aarch64 is missing.

Fix this by adding istarget "aarch64*-*-linux*".

Tested on aarch64-linux.

Approved-By: Luis Machado <luis.machado@arm.com>

Enable multi-process debugging for AIX

This patch adds multi-process debugging feature in AIX.

Till now AIX supported debugging only one inferior at a time,
now we can be able to debug multi process.  Users can use set
follow fork mode in child or parent and set detach on fork on
or off to enable/disable simultaneous debugging of parent/child.

Automatic date update in version.in

PowerPC, fix support for printing the function return value for non-trivial values.

Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC.  This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called.  The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function.  Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.

This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function.  This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary.  The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries.  This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function.  The GDB function should_stop checks
to see if RETURN_BUF is non-zero.  By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined.  The value_at function uses the
return buffer address to get the return value.

This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.

Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".

This patch has been tested on Power 10 and x86-64 with no regressions.

PowerPC, function ppc64_sysv_abi_return_value add missing return value convention

This patch address five testcase failures in gdb.cp/non-trivial-retval.exp.
The following commit resulted in the five testcases failures on PowerPC.
The value returned by the function is being reported incorrectly.

  commit b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608
  Author: Andrew Burgess <aburgess@redhat.com>
  Date:   Mon Dec 13 16:56:16 2021 +0000

      gdb: on x86-64 non-trivial C++ objects are returned in memory

      Fixes PR gdb/28681.  It was observed that after using the `finish`
      command an incorrect value was displayed in some cases.  Specifically,
      this behaviour was observed on an x86-64 target.

The function:

  enum return_value_convention
  ppc64_sysv_abi_return_value (struct gdbarch *gdbarch, struct value *function,
                               struct type *valtype, struct regcache *regcache,
                               gdb_byte *readbuf, const gdb_byte *writebuf)

should return RETURN_VALUE_STRUCT_CONVENTION if the valtype->code() is
TYPE_CODE_STRUCT and if the language_pass_by_reference is not
trivially_copyable.

This patch adds the needed code to return the value
RETURN_VALUE_STRUCT_CONVENTION in this case.

With this patch, the five test cases still fail but with the message "Value
returned has type: A. Cannot determine contents".  The PowerPC ABI stores
the address of the buffer containing the function return value in register
r3 on entry to the function.  However, the PowerPC ABI does not guarentee
that r3 will not be modified in the function.  So when the function returns,
the return buffer address cannot be reliably obtained from register r3.
Thus the message "Cannot determine contents" is appropriate in this case.

Remove dump_prefix_expression

Since the expression rewrite, dump_prefix_expression has been
misnamed.  This patch cleans this up by removing the function, turning
it into a method on struct expression.

aarch64: Add support for Common Short Sequence Compression extension

This patch adds support for the CSSC extension and its corresponding
instructions: ABS, CNT, CTZ, SMAX, UMAX, SMIN, UMIN.

gas/ChangeLog:

        * config/tc-aarch64.c (parse_operands): Handle new operand types.
        * doc/c-aarch64.texi: Document new extension.
        * testsuite/gas/aarch64/cssc.d: New test.
        * testsuite/gas/aarch64/cssc.s: New test.

include/ChangeLog:

        * opcode/aarch64.h (AARCH64_FEATURE_CSSC): New feature Macro.
        (enum aarch64_opnd): New operand types.
        (enum aarch64_insn_class): New instruction class.

opcodes/ChangeLog:

* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-opc-2.c: Regenerate.
* aarch64-opc.c (operand_general_constraint_met_p): Update for new
operand types.
(aarch64_print_operand): Likewise.
* aarch64-opc.h (enum aarch64_field_kind): Declare FLD_CSSC_imm8 field.
* aarch64-tbl.h (aarch64_feature_cssc): Define new feature set.
(CSSC): Define new feature set Macro.
(CSSC_INSN): Define new instruction type.
(aarch64_opcode_table): Add new instructions.

x86: fold special-operand insn attributes into a single enum

Attributes which aren't used together in any single insn template can be
converted from individual booleans to a single enum, as was done for a few
other attributes before. This is more space efficient. Collect together
all attributes which express special operand constraints (and which fit
the criteria for folding).

pru: bfd: Correct default to no execstack

Data and instruction memories are strictly separated, so it is not
possible to execute instructions from the stack memory on PRU.

I don't see any difference in testsuite results with or without this
change.

bfd/ChangeLog:

* elf32-pru.c (elf_backend_default_execstack): Define as 0.

ld/ChangeLog:

* testsuite/ld-elf/elf.exp (target_defaults_to_execstack):
Return 0 for pru.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

[gas] arm: Add support for new unwinder directive ".pacspval".

This patch adds the assembler support for the new unwinder
directive ".pacspval" and encodes this directives with opcode
"0xb5". This opcode indicates the unwinder to use effective
vsp as modifier for PAC validation.

gas/ChangeLog:

2022-11-07  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * doc/c-arm.texi: Document directive.
        * config/tc-arm.c (s_arm_unwind_pacspval): Define function.
        (md_pseudo_table): Add entry for pacspval directive.
        * testsuite/gas/arm/ehabi-pacbti-m.d: New test.
        * testsuite/gas/arm/ehabi-pacbti-m.s: Likewise.

[readelf] arm: Support for new pacbti unwind opcode 0xb5.

This patch adds readelf support for decoding the exception
table opcode "0xb5", which indicates to use effective vsp
as modifier for PAC validation as defined by EHABI
(https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf
Section 10.3).

binutils/ChangeLog:

2022-11-07  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * readelf.c (decode_arm_unwind_bytecode): Add entry to decode opcode 0xb5.

gdb/unittests: PR28413, suppress warnings generated by Gnulib

Gnulib generates a warning if the system version of certain functions
are used (to redirect the developer to use Gnulib version).  It caused a
compiler error when...

-   Compiled with Clang
-   -Werror is specified (by default)
-   C++ standard used by Clang is before C++17 (by default as of 15.0.0)
    when this unit test is activated.

This issue is raised as PR28413.

However, previous proposal to fix this issue (a "fix" to Gnulib):
<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00003.html>
was rejected because it ruins the intent of Gnulib warnings.

So, we need a Binutils/GDB-side solution.

This commit tries to address this issue on the GDB side.  We have
"include/diagnostics.h" to disable certain warnings only when necessary.

This commit suppresses the Gnulib warnings by surrounding entire #include
block with DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS to disable Gnulib-
generated warnings on all standard C++ header files.

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

arm: Add support for Cortex-X1C CPU.

This patch adds support for Cortex-X1C CPU in Arm.

bfd/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * cpu-arm.c (processors): Add Cortex-X1C CPU entry.

gas/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * NEWS: Update docs.
        * config/tc-arm.c (arm_cpus): Add cortex-x1c to -mcpu.
        * doc/c-arm.texi: Update docs.
        * testsuite/gas/arm/cpu-cortex-x1c.d: New test.

[gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=all

While looking at test-case gdb.arch/ppc64-symtab-cordic.exp I realized that
the test-case is too restrictive here:
...
if {![istarget "powerpc*"] || ![is_lp64_target]} {
    verbose "Skipping powerpc64 separate debug file symtab test."
    return
}
...
and can also be run on x86_64-linux, if "set arch powerpc:common64" is
supported, which is the case if we've build gdb with --enable-targets=all.

Fix this by instead checking if powerpc:common64 is in the completion list for
"set arch".

This allows us to remove the 'untested "powerpc:common64 is not supported"'.

While we're at it, clean up the test-case by using clean_restart.

Tested on x86_64-linux.

[gdb/testsuite] Handle with_set arch

I realized that the more irregular output of show arch:
...
(gdb) show arch^M
The target architecture is set to "auto" (currently "i386").^M
...
would be a problem for something like:
...
with_set arch powerpc:common64 {}
...
and indeed:
...
(gdb) set arch powerpc:common64^M
The target architecture is set to "powerpc:common64".^M
(gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
...
and:
...
(gdb) set arch set to "auto" (currently "i386")^M
Undefined item: "set".^M
...

Fix this in with_set by handling this type of output.

Tested on x86_64-linux.