Automatic date update in version.in

[gdb/testsuite] Fix have_mpx test

When testing on openSUSE Leap 15.4 I ran into this FAIL:
...
FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
...
and likewise for all the other mpx tests.

The problem is that have_mpx is supposed to return 0, but it doesn't because
it tries to match this output:
...
builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
No MPX support^M
No MPX support^M
...
using:
...
                   && ![string equal $output "No MPX support\r\n"]]
...

Fix this by matching using a regexp instead.

Tested on x86_64-linux.

use of uninitialised value in input_file_open

Triggered by a file containing just "#N" or "#A".  fgets when hitting
EOF before reading anything returns NULL and does not write to buf.
strchr (buf, '\n') then is reading from uninitialised memory.

* input-file.c (input_file_open): Don't assume buf contains
zero string terminator when fgets returns NULL.

Always free matching vector from bfd_check_format_matches

At least one place calling list_matching_formats failed to free the
"matching" vector from bfd_check_format_matches afterwards.  Fix that
by calling free inside list_matching_formats.

binutils/
* bucomm.c (list_matching_formats): Free arg.
* addr2line.c (process_file): Adjust to suit.
* ar.c (open_inarch, ranlib_touch): Likewise.
* coffdump.c (main): Likewise.
* nm.c (display_archive, display_file): Likewise.
* objcopy.c (copy_file): Likewise.
* objdump.c (display_object_bfd): Likewise.
* size.c (display_bfd): Likewise.
* srconv.c (main): Likewise.
ld/
* ldlang.c (load_symbols): Free "matching".

Revert "Revert "Fix fbsd core matching""

This reverts commit 476288fa2bddecf0f0e13dee826a076309bf01fe.

Restore readelf -wF

Commit 94585d6d4495 resulted in readelf -wF failing with
Unrecognized debug letter option 'F'

binutils/
* dwarf.c (debug_dump_long_opts): Add letter.
(debug_option_table): New, replacing..
(opts_table, letter_table): ..these.
(dwarf_select_sections_by_names): Adjust to suit.  Set
do_debug_frames outside of loop.
(dwarf_select_sections_by_letters): Similarly.
gas/
* testsuite/gas/i386/ehinterp.d: Use readelf -wF.

PR29250, readelf erases CIE initial register state

PR 29250
binutils/
* dwarf.c (display_debug_frames): Set col_type[reg] on sizing
pass over FDE to cie->col_type[reg] if CIE specifies reg.
Handle DW_CFA_restore and DW_CFA_restore_extended on second
pass using the same logic.  Remove unnecessary casts.  Don't
call frame_need_space on second pass over FDE.
gas/
* testsuite/gas/i386/ehinterp.d,
* testsuite/gas/i386/ehinterp.s: New test.
* testsuite/gas/i386/i386.exp: Run it.

Automatic date update in version.in

sim: fix BFD_VMA format arguments on 32-bit hosts [PR gdb/29184]

Noticed format mismatch when attempted to build gdb on i686-linux-gnu
in --enable-64-bit-bfd mode:

    sim/../../sim/cris/sim-if.c:576:28:
        error: format '%lx' expects argument of type 'long unsigned int',
        but argument 4 has type 'bfd_size_type' {aka 'long long unsigned int'} [-Werror=format=]
      576 |       sim_do_commandf (sd, "memory region 0x%" BFD_VMA_FMT "x,0x%lx",
          |                            ^~~~~~~~~~~~~~~~~~~
      577 |          interp_load_addr, interpsiz);
          |                            ~~~~~~~~~
          |                            |
          |                            bfd_size_type {aka long long unsigned int}

While at it fixed format string for time-related types.

Check for listeners in emit_exiting_event

I noticed that emit_exiting_event does not check whether there are any
listeners before creating the event object.  All other event emitters
do this, so this patch updates this one as well.

Add to documentation of Python 'dont_repeat' method

PR python/28533 points out that the Python 'dont_repeat' documentation
is a bit ambiguous about when the method ought to be called.  This
patch spells it out.

gdb/arm: Make sp alias for one of the other stack pointers

For Cortex-M targets, SP register is never detached from msp or
psp, it always has the same value as one of them.  Let GDB treat
ARM_SP_REGNUM as an alias similar to what is done in hardware.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/arm: Track msp and psp

For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns).  To be compatible
with earlier Cortex-M derivates, the msp and psp registers are
aliases for one of the 4 real stack pointer registers.

These are the combinations that exist:
sp -> msp -> msp_s
sp -> msp -> msp_ns
sp -> psp -> psp_s
sp -> psp -> psp_ns

This means that when the GDB client is to show the value of "msp",
the value should always be equal to either "msp_s" or "msp_ns".
Same goes for "psp".

To add a bit more context; GDB does not really use the register msp
(or psp) internally, but they are part of the set of registers which
are provided by the target.xml file.  As a result, they will be part
of the set of registers printed by the "info r" command.

Without this particular patch, GDB will hit the assert in the bottom
of arm_cache_get_sp_register function.

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

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/arm: Fetch initial sp value prior to compare

For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns).  In order to
identify the active one, compare the values of the different
stacks. The value of the initial sp register needs to be fetched to
perform this comparison.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb: unify two dis_asm_read_memory functions in disasm.c

After the recent restructuring of the disassembler code, GDB has ended
up with two identical class static functions, both called
dis_asm_read_memory, with identical implementations.

My first thought was to move these out of their respective classes,
and just make them global functions, then I'd only need a single
copy.

And maybe that's the right way to go.  But I disliked that by doing
that I loose the encapsulation of the method with the corresponding
disassembler class.

So, instead, I placed the static method into its own class, and had
both the gdb_non_printing_memory_disassembler and gdb_disassembler
classes inherit from this new class as an additional base-class.

In terms of code generated, I don't think there's any significant
difference with this approach, but I think this better reflects how
the function is closely tied to the disassembler.

There should be no user visible changes after this commit.

gdb: refactor the non-printing disassemblers

This commit started from an observation I made while working on some
other disassembler patches, that is, that the function
gdb_buffered_insn_length, is broken ... sort of.

I noticed that the gdb_buffered_insn_length function doesn't set up
the application data field if the disassemble_info structure.

Further, I noticed that some architectures, for example, ARM, require
that the application_data field be set, see gdb_print_insn_arm in
arm-tdep.c.

And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
likely crash.  Which is why I said only "sort of" broken.  Right now
we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
broken yet?

Anyway to prove to myself that there was a problem here I extended the
disassembler self tests in disasm-selftests.c to include a test of
gdb_buffered_insn_length.  As I run the test for all architectures, I
do indeed see GDB crash for ARM.

To fix this we need gdb_buffered_insn_length to create a disassembler
that inherits from gdb_disassemble_info, but we also need this new
disassembler to not print anything.

And so, I introduce a new gdb_non_printing_disassembler class, this is
a disassembler that doesn't print anything to the output stream.

I then observed that both ARC and S12Z also create non-printing
disassemblers, but these are slightly different.  While the
disassembler in gdb_non_printing_disassembler reads the instruction
from a buffer, the ARC and S12Z disassemblers read from target memory
using target_read_code.

And so, I further split gdb_non_printing_disassembler into two
sub-classes, gdb_non_printing_memory_disassembler and
gdb_non_printing_buffer_disassembler.

The new selftests now pass, but otherwise, there should be no user
visible changes after this commit.

gdb/python: implement the print_insn extension language hook

This commit extends the Python API to include disassembler support.

The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.

To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one.  This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.

The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:

  DisassembleInfo

      Similar to libopcodes disassemble_info structure, has read-only
  properties: address, architecture, and progspace.  And has methods:
  __init__, read_memory, and is_valid.

      Each time GDB wants an instruction disassembled, an instance of
  this class is passed to a user written disassembler function, by
  reading the properties, and calling the methods (and other support
  methods in the gdb.disassembler module) the user can perform and
  return the disassembly.

  Disassembler

      This is a base-class which user written disassemblers should
  inherit from.  This base class provides base implementations of
  __init__ and __call__ which the user written disassembler should
  override.

  DisassemblerResult

      This class can be used to hold the result of a call to the
  disassembler, it's really just a wrapper around a string (the text
  of the disassembled instruction) and a length (in bytes).  The user
  can return an instance of this class from Disassembler.__call__ to
  represent the newly disassembled instruction.

The gdb.disassembler module also provides the following functions:

  register_disassembler

      This function registers an instance of a Disassembler sub-class
  as a disassembler, either for one specific architecture, or, as a
  global disassembler for all architectures.

  builtin_disassemble

      This provides access to GDB's builtin disassembler.  A common
  use case that I see is augmenting the existing disassembler output.
  The user code can call this function to have GDB disassemble the
  instruction in the normal way.  The user gets back a
  DisassemblerResult object, which they can then read in order to
  augment the disassembler output in any way they wish.

      This function also provides a mechanism to intercept the
  disassemblers reads of memory, thus the user can adjust what GDB
  sees when it is disassembling.

The included documentation provides a more detailed description of the
API.

There is also a new CLI command added:

  maint info python-disassemblers

This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.

gdb: add extension language print_insn hook

This commit is setup for the next commit.

In the next commit I will add a Python API to intercept the print_insn
calls within GDB, each print_insn call is responsible for
disassembling, and printing one instruction.  After the next commit it
will be possible for a user to write Python code that either wraps
around the existing disassembler, or even, in extreme situations,
entirely replaces the existing disassembler.

This commit does not add any new Python API.

What this commit does is put the extension language framework in place
for a print_insn hook.  There's a new callback added to 'struct
extension_language_ops', which is then filled in with nullptr for Python
and Guile.

Finally, in the disassembler, the code is restructured so that the new
extension language function ext_lang_print_insn is called before we
delegate to gdbarch_print_insn.

After this, the next commit can focus entirely on providing a Python
implementation of the new print_insn callback.

There should be no user visible change after this commit.

gdb: add new base class to gdb_disassembler

The motivation for this change is an upcoming Python disassembler API
that I would like to add.  As part of that change I need to create a
new disassembler like class that contains a disassemble_info and a
gdbarch.  The management of these two objects is identical to how we
manage these objects within gdb_disassembler, so it might be tempting
for my new class to inherit from gdb_disassembler.

The problem however, is that gdb_disassembler has a tight connection
between its constructor, and its print_insn method.  In the
constructor the ui_file* that is passed in is replaced with a member
variable string_file*, and then in print_insn, the contents of the
member variable string_file are printed to the original ui_file*.

What this means is that the gdb_disassembler class has a tight
coupling between its constructor and print_insn; the class just isn't
intended to be used in a situation where print_insn is not going to be
called, which is how my (upcoming) sub-class would need to operate.

My solution then, is to separate out the management of the
disassemble_info and gdbarch into a new gdb_disassemble_info class,
and make this class a parent of gdb_disassembler.

In arm-tdep.c and mips-tdep.c, where we used to cast the
disassemble_info->application_data to a gdb_disassembler, we can now
cast to a gdb_disassemble_info as we only need to access the gdbarch
information.

Now, my new Python disassembler sub-class will still want to print
things to an output stream, and so we will want access to the
dis_asm_fprintf functionality for printing.

However, rather than move this printing code into the
gdb_disassemble_info base class, I have added yet another level of
hierarchy, a gdb_printing_disassembler, thus the class structure is
now:

  struct gdb_disassemble_info {};
  struct gdb_printing_disassembler : public gdb_disassemble_info {};
  struct gdb_disassembler : public gdb_printing_disassembler {};

In a later commit my new Python disassembler will inherit from
gdb_printing_disassembler.

The reason for adding the additional layer to the class hierarchy is
that in yet another commit I intend to rewrite the function
gdb_buffered_insn_length, and to do this I will be creating yet more
disassembler like classes, however, these will not print anything,
thus I will add a gdb_non_printing_disassembler class that also
inherits from gdb_disassemble_info.  Knowing that that change is
coming, I've gone with the above class hierarchy now.

There should be no user visible changes after this commit.

gdb/python: convert gdbpy_err_fetch to use gdbpy_ref

Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
removes the need for manual reference count management, and allows the
destructor to be removed.

There should be no functional change after this commit.

I think this cleanup is worth doing on its own, however, in a later
commit I will want to copy instances of gdbpy_err_fetch, and switching
to using gdbpy_ref means that I can rely on the default copy
constructor, without having to add one that handles the reference
counts, so this is good preparation for that upcoming change.

x86: drop print_operand_value()'s "hex" parameter

For quite some  time all callers have been passing 1 / true. While there
fold the final oappend_with_style() calls.

[gdb/build] Fix build for gcc < 11

When building trunk on openSUSE Leap 15.3 with system gcc 7.5.0, I run into:
...
In file included from ../bfd/bfd.h:46:0,
                 from gdb/defs.h:37,
                 from gdb/debuginfod-support.c:19:
gdb/debuginfod-support.c: In function ‘bool debuginfod_is_enabled()’:
gdb/../include/diagnostics.h:42:3: error: unknown option after \
  ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
   _Pragma (DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored option))
   ^
gdb/../include/diagnostics.h:80:3: note: in expansion of macro \
  ‘DIAGNOSTIC_IGNORE’
   DIAGNOSTIC_IGNORE ("-Wstringop-overread")
   ^~~~~~~~~~~~~~~~~
gdb/debuginfod-support.c:201:4: note: in expansion of macro \
  ‘DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD’
    DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
    ^
...

The problem is that the warning -Wstringop-overread has been introduced for
gcc 11, and we can only tell gcc to ignore if it knows about it.

Fix this by guarding the DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD definition in
diagnostics.c with '#if __GNUC__ >= 11'.

Tested on x86_64-linux, by completing a build.

PR29230, segv in lookup_symbol_in_variable_table

The PR23230 testcase uses indexed strings without specifying
SW_AT_str_offsets_base.  In this case we left u.str with garbage (from
u.val) which then led to a segfault when attempting to access the
string.  Fix that by clearing u.str.  The patch also adds missing
sanity checks in the recently committed read_indexed_address and
read_indexed_string functions.

PR 29230
* dwarf2.c (read_indexed_address): Return uint64_t.  Sanity check idx.
(read_indexed_string): Use uint64_t for str_offset.  Sanity check idx.
(read_attribute_value): Clear u.str for indexed string forms when
DW_AT_str_offsets_base is not yet read or missing.

gdb: Always suppress stringop-overread warning in debuginfod-support.c

Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11
on hppa produces a spurious warning for stringop-overread in
debuginfod_is_enabled for url_view. Just always suppress it on all
arches.

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

gdb/ChangeLog:

* debuginfod-support.c (debuginfod_is_enabled): Always use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.

Automatic date update in version.in

gprofng docs: provide help for <rate> == <interval>

The help message from 'gprofng collect app -h', in
the section on <rate> == <interval>, had a dangling
reference to a non-existent manpage. Provide basic
info, including reasons for caution.

gprofng docs: mention HTML / PDF in the gprofng README

The HTML and PDF formats are described in the gprofng tutorial (info
topic "Other Document Formats"). In addition, describe them in the
README because: they are important; they are easily searchable; and the
README is primarily oriented to the person who is installing gprofng,
who may differ from the person who follows a user tutorial.

gprofng: fix build with -Werror=format-security

gprofng/ChangeLog
2022-06-13  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/28968
* src/src/Hist_data.cc (print_row): Make param const.
* src/src/Hist_data.h (print_row): Likewise.
* src/src/Print.h: Remove unused functions and variables.
* src/Print.cc: Fix -Werror=format-security errors.
* src/parse.cc: Likewise.

[gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp

When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with
python 3.4, I occasionally run into:
...
Expecting: ^(-pycmd dct[^M
]+)?(\^done,result={hello="world",times="42"}[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd dct^M
^done,result={times="42",hello="world"}^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output)
...

The problem is that the data type used here in py-mi-cmd.py:
...
        elif argv[0] == "dct":
            return {"result": {"hello": "world", "times": 42}}
...
is a dictionary, and only starting version 3.6 are dictionaries insertion
ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a
fixed order.

Fix this by allowing the alternative order.

Tested on x86_64-linux.

Implement lazy FPU initialization for ravenscar

Some ravenscar runtimes implement lazy FPU handling.  On these
runtimes, the FPU is only initialized when a task tries to use it.
Furthermore, the FP registers aren't automatically saved on a task
switch -- instead, the save is deferred until the new task tries to
use the FPU.  Furthermore, each task's context area has a flag
indicating whether the FPU has been initialized for this task.

This patch teaches GDB to understand this implementation.  When
fetching or storing registers, GDB now checks to see whether the live
FP registers should be used.  If not, the task's saved FP registers
will be used if the task has caused FPU initialization.

Currently only AArch64 uses this code.  bb-runtimes implements this
for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.

Reimplement ravenscar registers using tables

Currently, the ravenscar-thread implementation for each architecture
is written by hand.  However, these are actually written by
copy-paste.  It seems better to switch to a table-driven approach.

The previous code also fetched all registers whenever any register was
requested.  This is corrected in the new implementation.

Fix bugs in aarch64-ravenscar-thread.c

We found a few bugs in aarch64-ravenscar-thread.c.

First, some of the register offsets were incorrect.  The "bb-runtimes"
file for this runtime had the wrong offsets in comments, which GDB
took to be correct.  However, those comments didn't account for
alignment.  This patch adjusts the offsets.

Next, the "FPU Saved field" is not a register -- it is an
implementation detail of the runtime.  This is removed.

Finally, I think the FP registers are actually named V0-V31, and the
"Q" names are pseudo-registers.  This patch fixes the comment.

Allow 'interrupt -a' in all-stop mode

PR gdb/17160 points out that "interrupt -a" errors in all-stop mode,
but there's no good reason for this.  This patch removes the error.

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

gdbserver: Add LoongArch/Linux support

Implement LoongArch/Linux support, including XML target description
handling based on features determined, GPR regset support, and software
breakpoint handling.

In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
set to yes.

With this patch on LoongArch:

  $ make check-gdb TESTS="gdb.server/server-connect.exp"
  [...]
  # of expected passes 18
  [...]

Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Revert "Fix fbsd core matching"

This reverts commit a7e29f797cecd5a2f73c27838b09eae1f1b6c657.

I accidentally pushed this, so revert.

[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp

With gcc-12 and target board unix/-m32, we run into:
...
(gdb) ^M
Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
]+)?(\^done,name="A_String_Access",numchild="1",.*[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create A_String_Access * A_String_Access^M
^error,msg="Value out of range."^M
(gdb) ^M
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...

What happens is easier to understand if we take things out of the mi context:
...
$ gdb -q -batch \
    outputs/gdb.ada/mi_var_access/mi_access \
    -ex "b mi_access.adb:19" \
    -ex run \
    -ex "p A_String_Access"
  ...
Breakpoint 1, mi_access () at mi_access.adb:19
19         A_String : String (3 .. 5) := "345"; -- STOP
$1 = (pck.string_access) <error reading variable: Value out of range.>
...
while with target board unix we have instead:
...
$1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks>
...

The var-create command samples the value of the variable at a location where
the variable is not yet initialized, and with target board unix we
accidentally hit a valid address, but with target board unix/-m32 that's not
the case.

Fix the FAIL by accepting the error message.

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

Fix fbsd core matching

On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote:
> On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote:
> > Hi,
> >
> > With an --enable-targets=all build and target board unix/-m32 I run into a
> > FAIL in test-case gdb.base/corefile.exp:
> > ...
> > (gdb) file outputs/gdb.base/corefile/corefile^M
> > Reading symbols from outputs/gdb.base/corefile/corefile...^M
> > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M
> > warning: core file may not match specified executable file.^M
> > [New LWP 12011]^M
> > Core was generated by `outputs/gdb.base/corefile/co'.^M
> > Program terminated with signal SIGABRT, Aborted.^M
> > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free
> > ...
> >
> > The warning is there because of this mismatch between core and exec:
> > ...
> > (gdb) p core_bfd->xvec
> > $3 = (const struct bfd_target *) 0x20112a0 <i386_elf32_fbsd_vec>
> > (gdb) p exec_bfd->xvec
> > $4 = (const struct bfd_target *) 0x2010b00 <i386_elf32_vec>
> > ...
> >
> > In the exec case, the detected architecture is i386_elf32_vec because this bit
> > of code in elfcode.h:elf_object_p():
> > ...
> >    if (ebd->elf_machine_code != EM_NONE
> >        && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi
> >        && ebd->elf_osabi != ELFOSABI_NONE)
> >      goto got_wrong_format_error;
> > ...
> > prevents i386_elf32_fbsd from matching.
> >
> > Fix the core matching by copying that code to elfcore.h:elf_core_file_p().
> >
> > Tested on x86_64-linux.
> >
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227
> >
> > Any comments?

Looks good.

> Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over
> time and is a bit rotted.  I suspect that all of changes made in commit 0aabe54e6222
> that added these lines in elfcode.h (along with several other changes) need to
> be applied to this function in elfcore.h, not just adding these lines.

Yes, the commit 0aabe54e6222 changes likely should go in too.  I'm a
little wary of adding all the sanity checks to elf_core_file_p since
that might result in some core files not being recognised at all.  For
example, despite the FIXME I'd guess leaving out the EI_VERSION check
was deliberate.  The following seems reasonable to me.  Please test.

Debug support for global alias variable

Starting with (future) Clang 15 (since
https://reviews.llvm.org/D120989), Clang emits the DWARF information
of global alias variables as DW_TAG_imported_declaration.  However,
GDB does not handle it.  It incorrectly always reads this tag as
C++/Fortran imported declaration (type alias, namespace alias and
Fortran module).  This commit adds support to handle this tag as an
alias variable.

This change fixes the failures in the gdb.base/symbol-alias.exp
testcase with current git Clang.  This testcase is also updated to
test nested (recursive) aliases.

BFD_RELOC_MIPS_16

MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation,
since R_MIPS_16 specifies a 16-bit field in a 32-bit word.
BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data
directives, expects fixups to operate on the whole of a 16-bit word.

This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd
reloc that is used to generate R_MIPS_16.  BFD_RELOC_16 is handled in
md_apply_fix for cases where the fixup can be applied at assembly
time.  Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object
file relocation, and thus .half, .hword, .short and .dc.w must be
resolved at assembly time.  BFD_RELOC_MIPS_REL16 is removed by this
patch since it isn't used.

PR 3243
PR 26542
* reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16.
* elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16.
* elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16.
* elfn32-mips.c (mips_reloc_map): Likewise.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
gas/
* config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16.
(macro_build): Likewise.
(mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16.
(md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done.
ld/
* testsuite/ld-mips-elf/reloc-local-overflow.d,
* testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite.

Correct R_MIPS_16 n32 howto

If the howto is actually used, an all-zero dst_mask will result in
unchanged section contents on attempting to apply R_MIPS_16.

* elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct
dst_mask.

asan: applying zero offset to NULL pointer

* dwarf.c (fetch_indexed_string): Move initialisation of "curr"
and "end" after checking for missing section.

gas dwarf2dbg.c tidy

Make it a little more obvious that remap_debug_filename returns an
allocated string (that should be freed) by returning a char * rather
than const char *.  Free a few missed cases in dwarf2dbg.c, and free
other memory allocated in dwarf2dbg.c.  Also remove static
initialisation of variables and initialise in dwarf2_init instead,
in order to ensure gas state is saner for oss-fuzz.

* remap.c (remap_debug_filename): Remove const from return.
* as.h (remap_debug_filename): Update prototype.
* config/obj-elf.c (obj_elf_ident): Simplify free of
remap_debug_filename output.
* stabs.c (stabs_generate_asm_file): Likewise.
* dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't
initialise statically..
(dwarf2_init): ..do so here, along with most other static vars.
(assign_file_to_slot): Don't set files_allocated until we
succeed in allocating memory.
(purge_generated_debug): Add bool param, free more stuff if true.
(dwarf2_directive_filename): Adjust purge_generated_debug call.
(process_entries): Don't free line_entry here..
(dwarf2_cleanup): ..do so here instead, new function.
(dwarf2_finish): Call dwarf2_cleanup.  When chaining together
subseg line entries, unhook entries from old subseg list.
(dwarf2_directive_loc): Free remap_debug_filename string.
(out_dir_and_file_list): Likewise.
(out_debug_str): Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo

When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo
installed, I run into:
...
(gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call
step^M
__tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \
  ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M
45      {^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW
...

The problem is that the step is expected to step over the call to tcsetattr,
but due to glibc debuginfo being installed, we step into the call.

Fix this by using next instead of step.

Tested on x86_64-linux.

[gdb] Avoid warnings in cooked_{read,write}_test for m68hc11

With --enable-targets=all we have:
...
$ gdb -q -batch -ex "maint selftest"
  ...
Running selftest regcache::cooked_read_test::m68hc11.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12:HCS12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
...

Likewise for regcache::cooked_write_test.

The warning has no use in the selftest context.

Fix this by skipping the specific selftests.

Tested on x86_64-linux.

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

gdb: LoongArch: Deal with atomic sequence

We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: don't use bashism in configure test

Results in configure output like:
```
checking for X... no
/var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator
checking whether to use babeltrace... auto
```

... when /bin/sh is provided by a POSIX-compliant shell, like dash,
instead of bash.

gdb:csky add support target-descriptions for CSKY arch

Registers in CSKY architecture included:
1. 32 gprs
2. 16 ars (alternative gprs used for quick interrupt)
3. hi, lo, pc
4. fr0~fr31, fcsr, fid, fesr
5. vr0~vr15
6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank)

For register names:
Except over control registers, other registers, like gprs, hi, lo ...
are fixed names. Among the 32*32 control registers, some used registers
will have fixed names, others will have a default name "cpxcry". 'x'
refers to bank, y refers index in the bank(a control register in bank
4 with index 14 will has a default name cp4cr14).

For register numbers in GDB:
We assign a fixed number to each register in GDB, like:
r0~r31 with 0~31
hi, lo with 36, 37
fpu/vpu with 40~71
...
described in function csky_get_supported_register_by_index().

Function csky_get_supported_tdesc_registers_count():
To calculate the total number of registers that GDB can analyze,
including those with fixed names and those with default register names.

Function csky_get_supported_register_by_index():
To find a supported struct csky_supported_tdesc_register, return a
struct include name with regnum via index.

Arrays csky_supported_tdesc_feature_names[]:
Include all supported feature names in tdesc-xmls.

We use the information described above to load the register description
file of the target from the stub. When loading, do a little check that
whether the register description file contains SP, LR and PC.

[gdb/testsuite] Handle quotes in gdb_py_module_available

On openSUSE Leap 42.3 with python 3.4, I run into:
...
(gdb) python import pygments^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
ImportError: No module named 'pygments'^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/style.exp: python import pygments
ERROR: unexpected output from python import
...
because gdb_py_module_available doesn't handle the single quotes around the
module name in the ImportError.

Fix this by allowing the single quotes.

Tested on x86_64-linux.

x86: fix incorrect indirection

Commit 384e201e5aec ("x86: properly initialize struct instr_info
instance(s)") was based on an improperly refreshed patch. Correct the
oversight.

x86: replace global scratch buffer

With its movement to the stack, and with the subsequent desire to
initialize the entire instr_info instances, this has become doubly
inefficient. Individual users have better knowledge of how big a buffer
they need, and in a number of cases going through an intermediate buffer
can be avoided altogether.

Having got confirmation that it wasn't intentional to print memory
operand displacements with inconsistent style, print_displacement() is
now using dis_style_address_offset consistently (eliminating the need
for callers to pass in a style).

While touching print_operand_value() also convert its "hex" parameter to
bool. And while altering (and moving) oappend_immediate(), fold
oappend_maybe_intel_with_style() into its only remaining caller. Finally
where doing adjustments, use snprintf() in favor of sprintf().

x86: avoid string copy when swapping Vex.W controlled operands

Now that op_out[] is an array of pointers, there's no need anymore to
copy strings. Simply swap the pointers.

x86: shrink prefix related disassembler state fields

By changing the values used for "artificial" prefix values,
all_prefixes[] can be shrunk to array of unsigned char. All that
additionally needs adjusting is the printing of possible apparently
standalone prefixes when recovering from longjmp(): Simply check
whether any prefixes were successfully decoded, to avoid converting
opcode bytes matching the "artificial" values to prefix mnemonics.

Similarly by re-arranging the bits assigned to PREFIX_* mask values
we can fit all segment register masks in a byte and hence shrink
active_seg_prefix to unsigned char.

Somewhat similarly with last_*_prefix representing offsets into the
opcode being disassembled, signed char is sufficient to hold all possible
values.

x86: properly initialize struct instr_info instance(s)

Commit 39fb369834a3 ("opcodes: Make i386-dis.c thread-safe") introduced
a lot of uninitialized data. Alan has in particular observed ubsan
taking issue with the loop inverting the order of operands, where
op_riprel[] - an array of bool - can hold values other than 0 or 1.

Move instantiation of struct instr_info into print_insn() (thus having
just a single central point), and make use of C99 dedicated initializers
to fill fields right in the initializer where possible. This way all
fields not explicitly initialized will be zero-filled, which in turn
allows dropping of some other explicit initialization later in the
function or in ckprefix(). Additionally this removes a lot of
indirection, as all "ins->info" uses can simply become "info".

Make one further arrangement though, to limit the amount of data needing
(zero)initializing on every invocation: Convert the op_out structure
member to just an array of pointers, with the actual arrays living
inside print_insn() (and, as befoe, having just their 1st char filled
with nul).

While there, instead of adjusting print_insn()'s forward declaration,
arrange for no such declaration to be needed in the first place.

Automatic date update in version.in

Fix self-test failure in addrmap

Mark pointed out that my recent addrmap C++-ficiation changes caused a
regression in the self-tests.  This patch fixes the problem by
updating this test not to allocate the mutable addrmap on an obstack.

Remove psymtab_addrmap

While working on addrmaps, I noticed that psymtab_addrmap is no longer
needed now.  It was introduced in ancient times as an optimization for
DWARF, but no other symbol reader was ever updated to use it.  Now
that DWARF does not use psymtabs, it can be deleted.

Use malloc for mutable addrmaps

Mutable addrmaps currently require an obstack.  This was probably done
to avoid having to call splay_tree_delete, but examination of the code
shows that all mutable obstacks have a limited lifetime -- now it's
simple to treat them as ordinary C++ objects, in some cases
stack-allocating them, and have a destructor to make the needed call.
This patch implements this change.

Remove addrmap::create_fixed

addrmap::create_fixed is just a simple wrapper for 'new', so remove it
in favor of uses of 'new'.

Remove addrmap_create_mutable

This removes addrmap_create_mutable in favor of using 'new' at the
spots where the addrmap is created.

Remove addrmap wrapper functions

This removes the various addrmap wrapper functions in favor of simple
method calls on the objects themselves.

Move addrmap classes to addrmap.h

This moves the addrmap class definitions to addrmap.h.  This is safe
to do now that the contents are private.

Privacy for addrmap_mutable

This changes addrmap_mutable so that its data members are private.

Privacy for addrmap_fixed

This changes addrmap_fixed so that its data members are private.
It also makes struct addrmap_transition private as well.

Use inheritance for addrmap

This is a simply C++-ification of the basics of addrmap: it uses
virtual methods rather than a table of function pointers, and it
changes the concrete implementations to be subclasses.

Trivial fixes to Cygwin build after 8fea1a81

* Remove a stray semicolon
* Restore dropped nullptr program argument in use of create_process() under CYGWIN

Simplify __USEWIDE

Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not
defined for Cygwin 1.5.  After that, it's always defined if __CYGWIN__
is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.

Simplify cygwin_buf_t

Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was
defined as char for Cygwin 1.5.  After that, it's always wchar_t, so
just use that.

Automatic date update in version.in

Automatic date update in version.in

Fix warning-avoidance initialization in xcoffread.c

With the registry rewrite series, on Fedora 34, I started seeing this
error in xcoffread.c:

../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’:
../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized]
  948 |   union internal_auxent fcn_aux_saved = main_aux;
      |                         ^~~~~~~~~~~~~
../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here
  933 |   union internal_auxent main_aux;
      |                         ^~~~~~~~

I don't know why this error started suddenly... that seems weird,
because it's not obviously related to the changes I made.

Looking into it, it seems this line was intended to avoid a similar
warning -- but since 'main_aux' is uninitialized at the point where it
is used, this fix was incomplete.

This patch avoids the warning by initializing using "{}".  I'm
checking this in.

Fix comparison of unsigned long int to int in record_linux_system_call.

The if statement in case gdb_sys_ioctl in function
record_linux_system_call in file gdb/linux-record.c is as follows:

   if (tmpulongest == tdep->ioctl_FIOCLEX
      || tmpulongest == tdep->ioctl_FIONCLEX
    ....
      || tmpulongest == tdep->ioctl_TCSETSW
     ...
   }

The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415.  The variable
ioctl_TCSETW is defined in gdb/linux-record.h as an int.  The TCSETW value
has the MSB set to one so it is a negative integer.  The comparison of the
unsigned long value tmpulongest to a negative integer value for
ioctl_TCSETSW fails.

This patch changes the declarations for the ioctl_* values in struct
linux_record_tdep to unsigned long to fix the comparisons between
tmpulongest and the tdep->ioctl_* values.

An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify
the gdb record_linux_system_call() if statement for the ioctl TCSETSW
succeeds.

This patch has been tested on Power 10 and Intel with no test failures.

PowerPC, correct the gdb ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF.

Some of the ioctl numbers are based on the size of kernel termios structure.
Currently the PowerPC GDB definitions are "hard coded" into the ioctl
number.

The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
defined in gdb/ppc-linux-tdep.c as:

  record_tdep->ioctl_TCGETS = 0x403c7413;
  record_tdep->ioctl_TCSETS = 0x803c7414;
  record_tdep->ioctl_TCSETSW = 0x803c7415;
  record_tdep->ioctl_TCSETSF = 0x803c7416;

Where the termios structure size is in hex digits [5:4] as 0x3c.

The definition for the PowerPC termios structure is given in:
  arch/powerpc/include/uapi/asm/termbits.h

The size of the termios data structure in this file is 0x2c not 0x3c.

This patch changes the hex digits for the size of the PowerPC termios size
in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
This patch also changes the hard coding to generate the number based on a
it easier to update the ioctl numbers.

gdb/testsuite: remove definition of true/false from gdb_compiler_info

Since pretty much forever the get_compiler_info function has included
these lines:

    # Most compilers will evaluate comparisons and other boolean
    # operations to 0 or 1.
    uplevel \#0 { set true 1 }
    uplevel \#0 { set false 0 }

These define global variables true (to 1) and false (to 0).

It seems odd to me that these globals are defined in
get_compiler_info, I guess maybe the original thinking was that if a
compiler had different true/false values then we would detect it there
and define true/false differently.

I don't think we should be bundling this logic into get_compiler_info,
it seems weird to me that in order to use $true/$false a user needs to
first call get_compiler_info.

It would be better I think if each test script that wants these
variables just defined them itself, if in the future we did need
different true/false values based on compiler version then we'd just
do:

  if { [test_compiler_info "some_pattern"] } {
    # Defined true/false one way...
  } else {
    # Defined true/false another way...
  }

But given the current true/false definitions have been in place since
at least 1999, I suspect this will not be needed any time soon.

Given that the definitions of true/false are so simple, right now my
suggestion is just to define them in each test script that wants
them (there's not that many).  If we ever did need more complex logic
then we can always add a function in gdb.exp that sets up these
globals, but that seems overkill for now.

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

Document the ARM_CC_FOR_TARGET testsuite variable

This variable is useful when exercising AArch64 multi-arch support (debugging
32-bit AArch32 executables).

Unfortunately it isn't well documented. This patch adds information about it
and explains how to use it.

[gdb/testsuite] Fix XPASS with gcc-12 in gdb.base/vla-struct-fields.exp

With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp:
...
(gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M
$7 = 1^M
(gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object
...

Fix this by limiting the xfailing to gcc-11 and earlier.  Also, limit the
xfailing to the equality test.

Tested on x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.ada/ghost.exp

On openSUSE Tumbleweed with gcc-12, I run into a timeout:
...
(gdb) print value^M
Multiple matches for value^M
[0] cancel^M
[1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \
    character) return character at a-strmap.adb:599^M
[2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M
[3] system.object_reader.value (<ref> system.object_reader.object_symbol) \
    return system.object_reader.uint64 at s-objrea.adb:2279^M
[4] system.traceback.symbolic.value (system.address) return string at \
    s-trasym.adb:200^M
> FAIL: gdb.ada/ghost.exp: print value (timeout)
print ghost_value^M
Argument must be choice number^M
(gdb) FAIL: gdb.ada/ghost.exp: print ghost_value
...

Fix this by prefixing value (as well as the other printed values) with the
package name:
...
(gdb) print pck.value^M
...

Tested on x86_64-linux.

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

Automatic date update in version.in

Minor fix to Python breakpoint event documentation

I noticed that the Python event documentation referred to the event's
"breakpoint" field as a function, whereas it is actually an attribute.
This patch fixes the error.

gdb/aarch64: fix 32-bit arm compatibility

GDB's ability to run 32-bit ARM processes on an AArch64 native target
is currently broken.  The test gdb.multi/multi-arch.exp currently
fails with a timeout.

The cause of these problems is the following three functions:

  aarch64_linux_nat_target::thread_architecture
  aarch64_linux_nat_target::fetch_registers
  aarch64_linux_nat_target::store_registers

What has happened, over time, is that these functions have been
modified, forgetting that any particular thread (running on the native
target) might be an ARM thread, or might be an AArch64 thread.

The problems always start with a line similar to this:

  aarch64_gdbarch_tdep *tdep
    = (aarch64_gdbarch_tdep *) gdbarch_tdep (inf->gdbarch);

The problem with this line is that if 'inf->gdbarch' is an ARM
architecture, then gdbarch_tdep will return a pointer to an
arm_gdbarch_tdep object, not an aarch64_gdbarch_tdep object.  The
result of the above cast will, as a consequence, be undefined.

In aarch64_linux_nat_target::thread_architecture, after the undefined
cast we then proceed to make use of TDEP, like this:

  if (vq == tdep->vq)
    return inf->gdbarch;

Obviously at this point the result is undefined, but, if this check
returns false we then proceed with this code:

  struct gdbarch_info info;
  info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64);
  info.id = (int *) (vq == 0 ? -1 : vq);
  return gdbarch_find_by_info (info);

As a consequence we will return an AArch64 gdbarch object for our ARM
thread!  Things go downhill from there on.

There are similar problems, with similar undefined behaviour, in the
fetch_registers and store_registers functions.

The solution is to make use of a check like this:

  if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32)

If the word size is 32 then we know we have an ARM architecture.  We
just need to make sure that we perform this check before trying to
read the tdep field.

In aarch64_linux_nat_target::thread_architecture a little reordering,
and the addition of the above check allows us to easily avoid the
undefined behaviour.

For fetch_registers and store_registers I made the decision to split
each of the functions into two new helper functions, and so
aarch64_linux_nat_target::fetch_registers now calls to either
aarch64_fetch_registers or aarch32_fetch_registers, and there's a
similar change for store_registers.

One thing I had to decide was whether to place the new aarch32_*
functions into the aarch32-linux-nat.c file.  In the end I decided to
NOT place the functions there, but instead leave them in
aarch64-linux-nat.c, my reasoning was this:

The existing functions in that file are shared from arm-linux-nat.c
and aarch64-linux-nat.c, this generic code to support 32-bit ARM
debugging from either native target.

In contrast, the two new aarch32 functions I have added _only_ make
sense when debugging on an AArch64 native target.  These function
shouldn't be called from arm-linux-nat.c at all, and so, if we places
the functions into aarch32-linux-nat.c, the functions would be built
into a 32-bit ARM GDB, but never used.

With that said, there's no technical reason why they couldn't go in
aarch32-linux-nat.c, so if that is preferred I'm happy to move them.

After this commit the gdb.multi/multi-arch.exp passes.

gdb/arm: Document and fix exception stack offsets

Add a description of exception entry context stacking and fix next
frame offset (at 0xA8 relative to R0 location) as well as FPU
registers ones (starting at 0x68 relative to R0).

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/arm: Simplify logic for updating addresses

Small performance improvement by fetching previous SP value only
once before the loop and reuse it to avoid fetching at every
iteration.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

Fix ARM_CC_FOR_TARGET handling

The previous patch that introduced the arm_cc_for_target procedure
moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
to tell tcl that ARM_CC_FOR_TARGET is a global.  As a result,
specifying ARM_CC_FOR_TARGET on the command line actually does
nothing.  This fixes it.

Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153

gdb/arm: Terminate unwinding when LR is 0xffffffff

ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states
that LR is set to 0xffffffff on reset.

ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set
to 0xffffffff on warm reset if Main Extension is implemented,
otherwise the value is unknown.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/testsuite: solve problems with compiler_info caching

After this commit:

  commit 44d469c5f85a4243462b8966722dafa62b602bf5
  Date:   Tue May 31 16:43:44 2022 +0200

      gdb/testsuite: add Fortran compiler identification to GDB

Some regressions were noticed:

  https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html

The problem is associated with how compiler_info variable is cached
between calls to get_compiler_info.

Even before the above commit, get_compiler_info supported two
language, C and C++.  Calling get_compiler_info would set the global
compiler_info based on the language passed as an argument to
get_compiler_info, and, in theory, compiler_info would not be updated
for the rest of the dejagnu run.

This obviously is slightly broken behaviour.  If the first call to
get_compiler_info was for the C++ language then compiler_info would be
set based on the C++ compiler in use, while if the first call to
get_compiler_info was for the C language then compiler_info would be
set based on the C compiler.

This probably wasn't very noticable, assuming a GCC based test
environment then in most cases the C and C++ compiler would be the
same version.

However, if the user starting playing with CC_FOR_TARGET or
CXX_FOR_TARGET, then they might not get the behaviour they expect.

Except, to make matters worse, most of the time, the user probably
would get the behaviour they expected .... except when they didn't!
I'll explain:

In gdb.exp we try to avoid global variables leaking between test
scripts, this is done with the help of the two procs
gdb_setup_known_globals and gdb_cleanup_globals.  All known globals
are recorded before a test script starts, and then, when the test
script ends, any new globals are deleted.

Normally, compiler_info is only set as a result of a test script
calling get_compiler_info or test_compiler_info.  This means that the
compiler_info global will not exist when the test script starts, but
will exist when the test script end, and so, the compiler_info
variable is deleted at the end of each test.

This means that, in reality, the compiler_info is recalculated once
for each test script, hence, if a test script just checks on the C
compiler, or just checks on the C++ compiler, then compiler_info will
be correct and the user will get the behaviour they expect.

However, if a single test script tries to check both the C and C++
compiler versions then this will not work (even before the above
commit).

The situation is made worse be the behaviour or the load_lib proc.
This proc (provided by dejagnu) will only load each library once.
This means that if a library defines a global, then this global would
normally be deleted at the end of the first test script that includes
the library.

As future attempts to load the library will not actually reload it,
then the global will not be redefined and would be missing for later
test scripts that also tried to load that library.

To work around this issue we override load_lib in gdb.exp, this new
version adds all globals from the newly loaded library to the list of
globals that should be preserved (not deleted).

And this is where things get interesting for us.  The library
trace-support.exp includes calls, at the file scope, to things like
is_amd64_regs_target, which cause get_compiler_info to be called.
This means that after loading the library the compiler_info global is
defined.

Our override of load_lib then decides that this new global has to be
preserved, and adds it to the gdb_persistent_globals array.

From that point on compiler_info will never be recomputed!

This commit addresses all the caching problems by doing the following:

Change the compiler_info global into compiler_info_cache global.  This
new global is an array, the keys of this array will be each of the
supported languages, and the values will be the compiler version for
that language.

Now, when we call get_compiler_info, if the compiler information for
the specific language has not been computed, then we do that, and add
it to the cache.

Next, compiler_info_cache is defined by calling
gdb_persistent_global.  This automatically adds the global to the list
of persistent globals.  Now the cache will not be deleted at the end
of each test script.

This means that, for a single test run, we will compute the compiler
version just once for each language, this result will then be cached
between test scripts.

Finally, the legacy 'gcc_compiled' flag is now only set when we call
get_compiler_info with the language 'c'.  Without making this change
the value of 'gcc_compiled' would change each time a new language is
passed to get_compiler_info.  If the last language was e.g. Fortran,
then gcc_compiled might be left false.

gdb/testsuite: handle errors better in test_compiler_info

Now that get_compiler_info might actually fail (if the language is not
handled), then we should try to handle this failure better in
test_compiler_info.

After this commit, if get_compiler_info fails then we will return a
suitable result depending on how the user called test_compiler_info.

If the user does something like:

  set version [test_compiler_info "" "unknown-language"]

Then test_compiler_info will return an empty string.  My assumption is
that the user will be trying to match 'version' against something, and
the empty string hopefully will not match.

If the user does something like:

  if { [test_compiler_info "some_pattern" "unknown-language"] } {
    ....
  }

Then test_compiler_info will return false which seems the obvious
choice.

There should be no change in the test results after this commit.

gdb/testsuite: make 'c' default language for get/test compiler info

This commit is a minor cleanup for the two functions (in gdb.exp)
get_compiler_info and test_compiler_info.

Instead of using the empty string as the default language, and just
"knowing" that this means the C language.  Make this explicit.  The
language argument now defaults to "c" if not specified, and the if
chain in get_compiler_info that checks the language not explicitly
handles "c" and gives an error for unknown languages.

This is a good thing, now that the API appears to take a language, if
somebody does:

  test_compiler_info "xxxx" "rust"

to check the version of the rust compiler then we will now give an
error rather than just using the C compiler and leaving the user
having to figure out why they are not getting the results they
expect.

After a little grepping, I think the only place we were explicitly
passing the empty string to either get_compiler_info or
test_compiler_info was in gdb_compile_shlib_1, this is now changed to
pass "c" as the default language.

There should be no changes to the test results after this commit.

gdb/testsuite: remove get_compiler_info calls from gdb.exp and dwarf.exp

We don't need to call get_compiler_info before calling
test_compiler_info; test_compiler_info includes a call to
get_compiler_info.

This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
removing some unneeded calls to get_compiler_info.  We could do the
same cleanup throughout the testsuite, but I'm leaving that for
another day.

There should be no change in the test results after this commit.

gdb/testsuite: use test_compiler_info in gcc_major_version

The procedure gcc_major_version was earlier using the global variable
compiler_info to retrieve gcc's major version.  This is discouraged and
(as can be read in a comment in compiler.c) compiler_info should be
local to get_compiler_info and test_compiler_info.

The preferred way of getting the compiler string is via calling
test_compiler_info without arguments.  Gcc_major_version was changed to
do that.

gdb: add Yvan Roux to gdb/MAINTAINERS

gdb/testsuite: resolve duplicate test names in gdb.threads/tls.exp

While running the gdb.threads/tls.exp test with a GDB configured
without Python, I noticed some duplicate test names.

This is caused by a call to skip_python_tests that is within a proc
that is called multiple times by the test script.  Each call to
skip_python_tests results in a call to 'unsupported', and this causes
the duplicate test names.

After this commit we now call skip_python_tests just once and place
the result into a variable.  Now, instead of calling skip_python_tests
multiple times, we just check the variable.

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

gdb/testsuite: resolve duplicate test name in gnu_vector.exp

While testing on AArch64 I spotted a duplicate test name in the
gdb.base/gnu_vector.exp test.

This commit adds a 'with_test_prefix' to resolve the duplicate.

While I was in the area I updated a 'gdb_test_multiple' call to make
use of $gdb_test_name.

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

Automatic date update in version.in

gdb: make throw_perror_with_name static

The throw_perror_with_name function is not used outside of utils.c
right now.  And as perror_with_name is just a wrapper around
throw_perror_with_name, then any future calls would be to
perror_with_name.

Lets make throw_perror_with_name static.

There should be no user visible changes after this commit.

gdb: remove trailing '.' from perror_with_name calls

I ran into this error while working on AArch64 GDB:

  Unable to fetch VFP registers.: Invalid argument.

Notice the '.:' in the middle of this error message.

This is because of this call in aarch64-linux-nat.c:

  perror_with_name (_("Unable to fetch VFP registers."));

The perror_with_name function take a string, and adds ': <message>' to
the end the string, so I don't think the string that we pass to
perror_with_name should end in '.'.

This commit removes all of the trailing '.' characters from
perror_with_name calls, which give more readable error messages.

I don't believe that any of these errors are tested in the
testsuite (after a little grepping).

Move CU queue to dwarf2_per_objfile

The CU queue is a member of dwarf2_per_bfd, but it is only used when
expanding CUs.  Also, the dwarf2_per_objfile destructor checks the
queue -- however, if the per-BFD object is destroyed first, this will
not work.  This was pointed out Lancelot as fallout from the patch to
rewrite the registry system.

This patch avoids this problem by moving the queue to the per-objfile
object.

Change allocation of m_dwarf2_cus

m_dwarf2_cus manually manages the 'dwarf2_cu' pointers it owns.  This
patch simplifies the code by changing it to use unique_ptr.

libopcodes: extend the styling within the i386 disassembler

The i386 disassembler is pretty complex.  Most disassembly is done
indirectly; operands are built into buffers within a struct instr_info
instance, before finally being printed later in the disassembly
process.

Sometimes the operand buffers are built in a different order to the
order in which they will eventually be printed.

Each operand can contain multiple components, e.g. multiple registers,
immediates, other textual elements (commas, brackets, etc).

When looking for how to apply styling I guess the ideal solution would
be to move away from the operands being a single string that is built
up, and instead have each operand be a list of "parts", where each
part is some text and a style.  Then, when we eventually print the
operand we would loop over the parts and print each part with the
correct style.

But it feels like a huge amount of work to move from where we are
now to that potentially ideal solution.  Plus, the above solution
would be pretty complex.

So, instead I propose a .... different solution here, one that works
with the existing infrastructure.

As each operand is built up, piece be piece, we pass through style
information.  This style information is then encoded into the operand
buffer (see below for details).  After this the code can continue to
operate as it does right now in order to manage the set of operand
buffers.

Then, as each operand is printed we can split the operand buffer into
chunks at the style marker boundaries, with each chunk being printed
with the correct style.

For encoding the style information I use a single character, currently
\002, followed by the style encoded as a single hex digit, followed
again by the \002 character.

This of course relies on there not being more than 16 styles, but that
is currently true, and hopefully will remain true for the foreseeable
future.

The other major concern that has arisen around this work is whether
the escape character could ever be encountered in output naturally
generated by the disassembler.  If this did happen then the escape
characters would be stripped from the output, and the wrong styling
would be applied.

However, I don't believe that this is currently a problem.
Disassembler content comes from a number of sources.  First there's
content that copied directly from the i386-dis.c file, this is things
like register names, and other syntax elements (brackets, commas,
etc).  We can easily check that the i386-dis.c file doesn't contain
our special character.

The next source of content are immediate operands.  The text for these
operands is generated by calls into libc.  By selecting a
non-printable character we can be confident that this is not something
that libc will generate as part of an immediate representation.

The other output that appears to be from the disassembler is operands
that contain addresses and (possibly) symbol names.  It is quite
possible that a symbol name might contain any special character we
could imagine, so is this a problem?

I don't think it is, we don't actually print address and symbol
operands through the disassembler, instead, the disassembler calls
back to the user (objdump, gdb, etc) to print the address and symbol
on its behalf.  This content is printed directly to the output stream,
it does not pass through the i386 disassembler output buffers.  As a
result, we never check this particular output for styling escape
characters.

In some (not very scientific) benchmarking on my machine,
disassembling a reasonably large (142M) shared library, I'm not seeing
any significant slow down in disassembler speed with this change.

Most instructions are now being fully syntax highlighted when I
disassemble using the --disassembler-color=extended-color option.  I'm
sure that there are probably still a few corner cases that need fixing
up, but we can come back to them later I think.

When disassembler syntax highlighting is not being used, then there
should be no user visible changes after this commit.

Fix gdb.arch/powerpc-power7.exp isel disassembly output.

The following commit changes the output format for the isel instruction on
PowerPC.

   commit dd4832bf3efc1bd1797a6b9188260692b8b0db52     Introduces error in test
   Author: Dmitry Selyutin <ghostmansd@gmail.com>
   Date:   Tue May 24 13:46:35 2022 +0000

       opcodes: introduce BC field; fix isel

       Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
       field present in binutils sources. Also, per 1.6.2, BC has the same
       semantics as BA and BB fields, so this should keep the same flags and
       mask, only with the different offset.

       opcodes/
               * ppc-opc.c
               (BC): Define new field, with the same definition as CRB field,
               but with the PPC_OPERAND_CR_BIT flag present.
       gas/
               * testsuite/gas/ppc/476.d: Update.
               * testsuite/gas/ppc/a2.d: Update.
               * testsuite/gas/ppc/e500.d: Update.
               * testsuite/gas/ppc/power7.d: Update.
  <snip>
   --- a/gas/testsuite/gas/ppc/476.d
   +++ b/gas/testsuite/gas/ppc/476.d
   @@ -209,7 +209,7 @@ Disassembly of section \.text:
    .*:    (7c 20 07 8c|8c 07 20 7c)       ici     1
    .*:    (7c 03 27 cc|cc 27 03 7c)       icread  r3,r4
    .*:    (50 83 65 36|36 65 83 50)       rlwimi  r3,r4,12,20,27
    -.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,28
    +.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,4\*cr7\+lt

The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
on Power 7, Power 8, Power 9 and Power 10.

This patch updates the regression test gdb.arch/powerpc-power7.exp with
the new expected output for the isel instruction.

The patch has been tested on Power 7 and Power 10 to verify the patch fixes
the test.

aarch64: Add fallback if ARM_CC_FOR_TARGET not set

On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
compiler to use when testing gdb.multi/multi-arch.exp and
gdb.multi/multi-arch-exec.exp.  If you don't set it, then those
testcases don't run.

I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.

This commit adds a fallback.  If ARM_CC_FOR_TARGET is not set, and
testing for Linux, try arm-linux-gnueabi-gcc,
arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
compilers, making sure that the produced executable runs on the target
machine before claiming that the compiler produces useful executables.

Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39