dllwrap, windres and dlltools use mktemp, which should be avoided

PR 29534
* dllwrap.c: Replace uses of choose_temp_base() with
make_temp_file().
* dlltool.c: Likewise.
* resrc.c: Likewise.

GDB/doc: Document the Guile `#:unlimited' keyword

Document the Guile `#:unlimited' keyword and deprecate the internal
integer representation it corresponds to for integer parameters.

gdb/python-config: replace deprecated distutils.sysconfig

When running the gdb/configure script on ubuntu 22.04 with
python-3.10.4, I see:

    checking for python... no
    checking for python3... /usr/bin/python3
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
      from distutils import sysconfig
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
      from distutils import sysconfig
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
      from distutils import sysconfig
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
      from distutils import sysconfig
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
      from distutils import sysconfig
    [...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
      from distutils import sysconfig
    checking for python... yes

The distutils module is deprecated as per the PEP 632[1] and will be
removed in python-3.12.

This patch migrates gdb/python/python-config.py from distutils.sysconfig
to the sysconfig module[2].

The sysconfig module has has been introduced in the standard library in
python 3.2.  Given that support for python < 3.2 has been removed by
edae3fd6600f: "gdb/python: remove Python 2 support", this patch does not
need to support both implementations for backward compatibility.

Tested on ubuntu-22.04 and ubuntu 20.04.

[1] https://peps.python.org/pep-0632/
[2] https://docs.python.org/3/library/sysconfig.html

Change-Id: Id0df2baf3ee6ce68bd01c236b829ab4c0a4526f6

Automatic date update in version.in

Fix interpreter-exec crash

PR mi/10347 points out that using interpreter-exec inside of a
"define" command will crash gdb.  The bug here is that
gdb_setup_readline doesn't check for the case where instream==nullptr.

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

Fix "source" with interpreter-exec

PR mi/15811 points out that "source"ing a file that uses
interpreter-exec will put gdb in a weird state, where the CLI stops
working.  The bug is that tui_interp::suspend does not unregister the
event file descriptor.

The test case is from Andrew Burgess.

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

Remove a call to clear_interpreter_hooks

mi_interp::resume does not need to call clear_interpreter_hooks,
because this is already done by interp_set.

TUI stdout buffering cleanup

The TUI checks against gdb_stdout to decide when to buffer.  It seems
much cleaner to me to simply record this as an attribute of the stream
itself.

Remove a ui-related memory leak

gdb_setup_readline makes new streams and assigns to the various stream
members of struct ui.  However, these assignments cause the previous
values to leak.  As far as I can, this code is simply unnecessary and
can be removed -- with the exception of the assignment to gdb_stdtarg,
which is not initialized anywhere else.

Remove tui_out_new

tui_out_new is just a simple wrapper for 'new' and can be removed,
simplifying gdb a tiny bit.

Use scoped_restore in safe_parse_type

This changes safe_parse_type to use scoped_restore rather than
explicit assignments.

Use member initialization in 'struct ui'

This changes 'struct ui' to use member initialization.  This is
simpler to understand.

Remove two unused members from mi_interp

These members of mi_interp aren't used and can be removed.

Remove obsolete filtering comment

top.h has an obsolete comment about the use of _unfiltered.

Remove the "for moment" comments

A few spots setting some gdb output stream variables have a "for
moment" comment.  These comments aren't useful and I think the moment
has passed -- these are permanent now.

Use ui_out_redirect_pop in more places

This changes ui_out_redirect_pop to also perform the redirection, and
then updates several sites to use this, rather than explicit
redirects.

Free ui::line_buffer

A ui initializes its line_buffer, but never calls buffer_free on it.
This patch fixes the oversight.  I found this by inspection.

Remove some dead code

This patch removes some dead code and an old FIXME.  These no longer
seem useful, even for documentation purposes.

Let ui::input_fd be -1

This changes gdb so that, if ui::input_fd is set to -1, then it will
not be registered with the event loop.  This is useful for the DAP
support code I wrote, but as it turns out to also be useful to
Insight, it seems best to check it in separately.

gdb/riscv: better support for fflags and frm registers

First, some background on the RISC-V registers fflags, frm, and fcsr.

These three registers all relate to the floating-point status and
control mechanism on RISC-V.  The fcsr is the floatint-point control
status register, and consists of two parts, the flags (bits 0 to 4)
and the rounding-mode (bits 5 to 7).

The fcsr register is just one of many control/status registers (or
CSRs) available on RISC-V.  The fflags and frm registers are also
CSRs.  These CSRs are aliases for the relevant parts of the fcsr
register.  So fflags is an alias for bits 0 to 4 of fcsr, and frm is
an alias for bits 5 to 7 of fcsr.

This means that a user can change the floating-point rounding mode
either, by writing a complete new value into fcsr, or by writing just
the rounding mode into frm.

How this impacts on GDB is like this: a target description could,
legitimately include all three registers, fcsr, fflags, and frm.  The
QEMU target currently does this, and this makes sense.  The target is
emulating the complete system, and has all three CSRs available, so
why not tell GDB about this.

In contrast, the RISC-V native Linux target only has access to the
fcsr.  This is because the ptrace data structure that the kernel uses
for reading and writing floating point state only contains a copy of
the fcsr, after all, this one field really contains both the fflags
and frm fields, so why carry around duplicate data.

So, we might expect that the target description for the RISC-V native
Linux GDB would only contain the fcsr register.  Unfortunately, this
is not the case.  The RISC-V native Linux target uses GDB's builtin
target descriptions by calling riscv_lookup_target_description, this
will then add an fpu feature from gdb/features/riscv, either
32bit-fpu.xml or 64bit-fpu.xml.  The problem, is that these features
include an entry for fcsr, fflags, and frm.  This means that GDB
expects the target to handle reading and writing these registers.  And
the RISC-V native Linux target currently doesn't.

In riscv_linux_nat_target::store_registers and
riscv_linux_nat_target::fetch_registers only the fcsr register is
handled, this means that, for RISC-V native Linux, the fflags and frm
registers always show up as <unavailable> - they are present in the
target description, but the target doesn't know how to access the
registers.

A final complication relating to these floating pointer CSRs is which
target description feature the registers appear in.

These registers are CSRs, so it would seem sensible that these
registers should appear in the CSR target description feature.

However, when I first added RISC-V target description support, I was
using a RISC-V simulator that didn't support any CSRs other than the
floating point related ones.  This simulator bundled all the float
related CSRs into the fpu target feature.  This didn't feel completely
unreasonable to me, and so I had GDB check for these registers in
either target feature.

In this commit I make some changes relating to how GDB handles the
three floating point CSR:

1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml.  This
means that the default RISC-V target description (which RISC-V native
FreeBSD), and the target descriptions created for RISC-V native Linux,
will not include these registers.  There's nothing stopping some other
target (e.g. QEMU) from continuing to include all three of these CSRs,
the code in riscv-tdep.c continues to check for all three of these
registers, and will handle them correctly if they are present.

2. If a target supplied fcsr, but does not supply fflags and/or frm,
then RISC-V GDB will now create two pseudo registers in order to
emulate the two missing CSRs.  These new pseudo-registers do the
obvious thing of just reading and writing the fcsr register.

3. With the new pseudo-registers we can no longer make use of the GDB
register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
These will be the numbers used if the target supplies the registers in
its target description, but, if GDB falls back to using
pseudo-registers, then new, unique numbers will be used.  To handle
this I've added riscv_gdbarch_tdep::fflags_regnum and
riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
compare against these fields.

When adding the pseudo-register support, it is important that the
pseudo-register numbers are calculated after the call to
tdesc_use_registers.  This is because we don't know the total number
of physical registers until after this call, and the psuedo-register
numbers must follow on from the real (target supplied) registers.

I've updated some tests to include more testing of the fflags and frm
registers, as well as adding a new test.

gdb: Add tdesc_found_register function to tdesc API

This commit adds a new function to the target description API within
GDB.  This new function is not used in this commit, but will be used
in the next commit, I'm splitting it out into a separate patch for
easier review.

What I want to do in the next commit is check to see if a target
description supplied a particular register, however, the register in
question could appear in one of two possible features.

The new function allows me to ask the tdesc_arch_data whether a
register was found and assigned a particular GDB register number once
all of the features have been checked.  I think this is a much simpler
solution than adding code such that, while checking each feature, I
spot if the register I'm processing is the one I care about.

No tests here as the new code is not used, but this code will be
exercised in the next commit.

gdb/riscv: improve (and fix) display of frm field in 'info registers'

On RISC-V the FCSR (float control/status register) is split into two
parts, FFLAGS (the flags) and FRM (the rounding mode).  Both of these
two fields are part of the FCSR register, but can also be accessed as
separate registers in their own right.  And so, we have three separate
registers, $fflags, $frm, and $fcsr, with the last of these being the
combination of the first two.

Here's how the bits of FCSR are split between FRM and FFLAGS:

         ,--------- FFLAGS
       |---|
    76543210 <----- FCSR
    |-|
     '--------------FRM

Here's how GDB currently displays these registers:

  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]
  fcsr           0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]

Notice the 'RD' field which is present in both $fflags and $fcsr.
This field contains the value of the FRM field, which makes sense when
displaying the $fcsr, but makes no sense when displaying $fflags, as
the $fflags doesn't include the FRM field.

Additionally, the $fcsr already includes an FRM field, so the
information in 'RD' is duplicated.  Consider this:

  (gdb) set $frm = 0x3
  (gdb) info registers $fflags $frm $fcsr                             │
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x3      FRM:3 [RUP (Round up towards +INF)]
  fcsr           0x60     RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]

See how the 'RD' field in $fflags still displays 0, while the 'RD' and
'FRM' fields in $fcsr show the same information.

The first change I propose in this commit is to remove the 'RD'
field.  After this change the output now looks like this:

  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]
  fcsr           0x0      NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]

Next, I spotted that the text that goes along with the 'FRM' field was
not wrapped in the i18n markers for internationalisation, so I added
those.

Next, I spotted that:

  (gdb) set $frm=0x7
  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x7      FRM:3 [RUP (Round up towards +INF)]
  fcsr           0xe0     RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]

Notice that despite being a 3-bit field, FRM masks to 2-bits.
Checking the manual I can see that the FRM field is 3-bits, and is
defined for all 8 values.  That GDB masks to 2-bits is just a bug I
think, so I've fixed this.

Finally, the 'FRM' text for value 0x7 is wrong.  Currently we use the
text 'dynamic rounding mode' for value 0x7.  However, this is not
really correct.

A RISC-V instruction can either encode the rounding mode within the
instruction, or a RISC-V instruction can choose to use a global,
dynamic rounding mode.

So, for the rounding-mode field of an _instruction_ the value 0x7
indicates "dynamic round mode", the instruction should defer to the
rounding mode held in the FRM field of the $fcsr.

But it makes no sense for the FRM of $fcsr to itself be set to
0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
Control and Status Register" of the RISC-V manual, says that a value
of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
_its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
then an illegal instruction exception is raised.

And so, I propose changing the text for value 0x7 of the FRM field to
be "INVALID[7] (Dynamic rounding mode)".  We already use the text
"INVALID[5]" and "INVALID[6]" for the two other invalid fields,
however, I think adding the extra "Dynamic round mode" hint might be
helpful.

I've added a new test that uses 'info registers' to check what GDB
prints for the three registers related to this patch.  There is one
slight oddity with this test - for the fflags and frm registers, the
test accepts both the "normal" output (as described above), but also
allows these registers to be reported as '<unavailable>'.

The reason why I accept <unavailable> is that currently, the RISC-V,
native Linux target advertises these registers in its target
description, but then doesn't support reading or writing of these
registers, this results in the registers being reported as
unavailable.

A later patch in this series will address this issue, and will remove
this check for <unavailable>.

Add OpenBSD AArch64 GAS support.

* configure.tgt (aarch64*-*-openbsd*): Add target.

gdb, dwarf: create symbols for template tags without names

The following GDB behavior was also reported as a GDB bug in

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

I will reiterate the problem a bit and give some more information here.
This patch closes the above mentioned bug.

The DWARF 5 standard 2.23 'Template Parameters' reads:

   A template type parameter is represented by a debugging information
   entry with the tag DW_TAG_template_type_parameter.  A template value
   parameter is represented by a debugging information entry with the tag
   DW_TAG_template_value_parameter.  The actual template parameter entries
   appear in the same order as the corresponding template formal
   parameter declarations in the source progam.

   A type or value parameter entry may have a DW_AT_name attribute, whose
   value is a null-terminated string containing the name of the
   corresponding formal parameter.

So the DW_AT_name attribute for DW_TAG_template_type_parameter and
DW_TAG_template_value_parameter is optional.

Within GDB, creating a new symbol from some read DIE usually requires the
presence of a DW_AT_name for the DIE (an exception here is the case of
unnamed namespaces or the existence of a linkage name).

This patch makes the presence of the DW_AT_name for template value/type
tags optional, similar to the unnamed namespaces.

For unnamed namespaces dwarf2_name simply returns the constant string
CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'.  For template tags a
case was added to the switch statement calling the
unnamed_template_tag_name helper.  Within the scope of parent which
the template parameter is a child of, the helper counts the position
of the template tag within the unnamed template tags and returns
'<unnamedNUMBER>' where NUMBER is its position.  This way we end up with
unique names within the respective scope of the function/class/struct
(these are the only currenltly supported template kinds within GDB and
usually the compilers) where we discovered the template tags in.

While I do not know of a way to bring GCC to emit template tags without
names there is one for clang/icpx.  Consider the following example

  template<typename A, typename B, typename C>
  class Foo {};

  template<typename, typename B, typename>
  class Foo;

  int main () {
    Foo<double, int, float> f;
    return 0;
  }

The forward declaration for 'Foo' with the missing template type names
'A' and 'C' makes clang emit a bunch of template tags without names:

 ...
  <2><43>: Abbrev Number: 3 (DW_TAG_variable)
    <44>   DW_AT_location    : 2 byte block: 91 78      (DW_OP_fbreg: -8)
    <47>   DW_AT_name        : (indirect string, offset: 0x63): f
    <4b>   DW_AT_decl_file   : 1
    <4c>   DW_AT_decl_line   : 8
    <4d>   DW_AT_type        : <0x59>
 ...
 <1><59>: Abbrev Number: 5 (DW_TAG_class_type)
    <5a>   DW_AT_calling_convention: 5  (pass by value)
    <5b>   DW_AT_name        : (indirect string, offset: 0x74): Foo<double, int, float>
    <5f>   DW_AT_byte_size   : 1
    <60>   DW_AT_decl_file   : 1
    <61>   DW_AT_decl_line   : 2
 <2><62>: Abbrev Number: 6 (DW_TAG_template_type_param)
    <63>   DW_AT_type        : <0x76>
 <2><67>: Abbrev Number: 7 (DW_TAG_template_type_param)
    <68>   DW_AT_type        : <0x52>
    <6c>   DW_AT_name        : (indirect string, offset: 0x6c): B
 <2><70>: Abbrev Number: 6 (DW_TAG_template_type_param)
    <71>   DW_AT_type        : <0x7d>
 ...

Befor this patch, GDB would not create any symbols for the read template
tag DIEs and thus lose knowledge about them.  Breaking at the return
statement and printing f's type would read

  (gdb) ptype f
  type = class Foo<double, int, float> [with B = int] {
      <no data fields>
  }

After this patch GDB does generate symbols from the DWARF (with their
artificial names:

  (gdb) ptype f
  type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
  <unnamed1> = float] {
      <no data fields>
  }

The same principle theoretically applies to template functions.  Also
here, GDB would not record unnamed template TAGs but I know of no visual
way to trigger and test this changed behavior.  Template functions do
not emit a '[with...]' list and their name generation also does not
suffer from template tags without names.  GDB does not check whether or
not a template tag has a name in 'dwarf2_compute_name' and thus, the
names of the template functions are created independently of whether or
not the template TAGs have a DW_TAT_name attribute.  A testcase has
been added in the gdb.dwarf2 for template classes and structs.

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

gdb, testsuite: adapt function_range expected name

When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.

However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.

The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name.  This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.

An example might make this more clear.  Given the following code

  >> cat c.cpp
  int foo (int a, float b)
  {
    return 0;
  }

  int main (int argc, char **argv)
  {
    return 0;
  }

which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:

  >> clang --version
  clang version 10.0.0-4ubuntu1
  ...
  >> clang -O0 -g ./c.cpp
  >> gdb -q ./a.out -ex "start"
  ...
  (gdb) disassemble main
  Dump of assembler code for function main(int, char**):
     0x0000000000401120 <+0>:     push   %rbp
     0x0000000000401121 <+1>:     mov    %rsp,%rbp
  ...
     0x0000000000401135 <+21>:    ret
  End of assembler dump.
  (gdb) disassemble foo
  Dump of assembler code for function _Z3fooif:
     0x0000000000401110 <+0>:     push   %rbp
     0x0000000000401111 <+1>:     mov    %rsp,%rbp
  ...
     0x000000000040111f <+15>:    ret
  End of assembler dump.

Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:

  >> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
      <2b>   DW_AT_low_pc      : 0x401110
      <33>   DW_AT_high_pc     : 0x10
      <37>   DW_AT_frame_base  : 1 byte block: 56         (DW_OP_reg6 (rbp))
      <39>   DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
      <3d>   DW_AT_name        : (indirect string, offset: 0x42): foo
      <41>   DW_AT_decl_file   : 1
      <42>   DW_AT_decl_line   : 1
      <43>   DW_AT_type        : <0x9a>

Now, let's rename the C++ file and compile it as C:

  >> mv c.cpp c.c
  >> clang -O0 -g ./c.c
  >> gdb -q ./a.out -ex "start'
  ...
  (gdb) disassemble main
  Dump of assembler code for function main:
     0x0000000000401120 <+0>:     push   %rbp
     0x0000000000401121 <+1>:     mov    %rsp,%rbp
  ...
     0x0000000000401135 <+21>:    ret
  End of assembler dump.
  (gdb) disassemble foo
  Dump of assembler code for function foo:
     0x0000000000401110 <+0>:     push   %rbp
     0x0000000000401111 <+1>:     mov    %rsp,%rbp
  ...
     0x000000000040111f <+15>:    ret
  End of assembler dump.

Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:

  >> objdump --dwarf=info ./a.out | grep foo -A3 -B3
      <2b>   DW_AT_low_pc      : 0x401110
      <33>   DW_AT_high_pc     : 0x10
      <37>   DW_AT_frame_base  : 1 byte block: 56         (DW_OP_reg6 (rbp))
      <39>   DW_AT_name        : (indirect string, offset: 0x37): foo
      <3d>   DW_AT_decl_file   : 1
      <3e>   DW_AT_decl_line   : 1
      <3f>   DW_AT_prototyped  : 1

To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range.  This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.

Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

gdb/elfread.c: Use bfd filename instead of objfile->original_name

The call to debuginfod_debuginfo_query in elf_symfile_read is given
objfile->original_name as the filename to print when downloading the
objfile's debuginfo.

In some cases original_name is prefixed with gdb's working directory
even though the objfile is not located in the working directory. This
causes debuginfod to display the wrong path of the objfile during a download.

Fix this by using the objfile's bfd filename instead.

Automatic date update in version.in

ld: pe: Fix linking against Microsoft import libraries with multiple DLLs

Initially, since c6c37250e98f113755e0d787f7070e2ac80ce77e (in 1999),
in order to fix linking against Microsoft import libraries, ld did
internally rename members of such libraries. At that point, the
criteria for being considered a Microsoft import library was that
every archive member had the same name (no regard for exactly what
that name was).

This was later amended in 44dbf3639f127af46d569ad96b6242dfbc4c0a89
(in 2003) to allow for Microsoft import libraries with intermixed
static object files. At this point, the criteria were extended, so
that all members following the first member named *.dll either had
the exact same member name, or be named *.obj. (Curiously, this would
allow members with any name if it precedes the first one named *.dll.)

In practice, Microsoft style import libraries can contain
members for linking against more than one DLL (built by merging
multiple regular import libraries into one).

Instead of trying to do validation of the whole archive before
considering it a Microsoft style import library, relax the criteria
for doing the member renaming: If an archive member is named *.dll
and it contains .idata sections, assume that that member is a
Microsoft import file, and apply the renaming scheme.

This works for imports for any number of DLLs in the same library,
intermixed with other static object files (regardless of their
names), and vastly simplifies the code.

LLVM generates Microsoft style import libraries, and Rust builds
seem to bundle up multiple import libraries together with some
Rust specific static objects. This fixes linking directly against
them with ld.bfd.

gdbsupport: add wrapper around result_of and invoke_result

When building with Clang 14 (using gcc 12 libstdc++ headers), I get:

      CXX    dwarf2/read.o
    In file included from /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:94:
    /home/simark/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:142:21: error: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' is deprecated: use 'std::invoke_result' instead [-Werror,-Wdeprecated-declarations]
        = typename std::result_of<RangeFunction (RandomIt, RandomIt)>::type;
                        ^
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7122:14: note: in instantiation of function template specialization 'gdb::parallel_for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, (lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5)>' requested here
          = gdb::parallel_for_each (1, per_bfd->all_comp_units.begin (),
                 ^
    /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/type_traits:2597:9: note: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' has been explicitly marked deprecated here
        { } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result");
            ^
    /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:120:45: note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST'
    # define _GLIBCXX17_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
                                                ^
    /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:96:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
      __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
                      ^

It complains about the use of std::result_of, which is deprecated in
C++17 and removed in C++20:

  https://en.cppreference.com/w/cpp/types/result_of

Given we'll have to transition to std::invoke_result eventually, make a
GDB wrapper to mimimc std::invoke_result, which uses std::invoke_result
for C++ >= 17 and std::result_of otherwise.  This way, it will be easy
to remove the wrapper in the future, just replace gdb:: with std::.

Tested by building with gcc 12 in -std=c++11 and -std=c++17 mode, and
clang in -std=c++17 mode (I did not test fully with clang in -std=c++11
mode because there are other unrelated issues).

Change-Id: I50debde0a3307a7bc67fcf8fceefda51860efc1d

Fix flush for sys.stderr

GDB overwrites Python's sys.stdout and sys.stderr, but does not
properly implement the 'flush' method -- it only ever will flush
stdout.  This patch fixes the bug.  I couldn't find a straightforward
way to write a test for this.

Fix gdb.flush documentation

The gdb.flush documentation does not mention the 'stream' argument in
the function signature, only in the description.  This patch fixes the
oversight.

BFD library: Use entry 0 in directory and filename tables of DWARF-5 debug info.

PR 29529
* dwarf2.c (struct line_info_table): Add new field:
use_dir_and_file_0.
(concat_filename): Use new field to help select the correct table
slot.
(read_formatted_entries): Do not skip entry 0.
(decode_line_info): Set new field depending upon the version of
DWARF being parsed.  Initialise filename based upon the setting of
the new field.

gdb: update ranged_breakpoint::print_one_detail in comments

The print_one_detail_ranged_breakpoint has been renamed to
ranged_breakpoint::print_one_detail in this commit:

  commit ec45bb676c9c69c30783bcf35ffdac8280f3b8bc
  Date:   Sat Jan 15 16:34:51 2022 -0700

    Convert ranged breakpoints to vtable ops

So their comments should be updated as well.

Add a testcase for PR 29494.

PR 29494
* testsuite/gas/arm/pr29494.s: New test source file.
* testsuite/gas/arm/pr29494.d: New test driver.

LoongArch: Fix redefinition of "PACKAGE".

  Running configure and make in binutils-gdb.

  $ ./configure
  $ make
In file included from ./as.h:37,
                 from ./config/loongarch-lex.l:21,
                 from config/loongarch-lex-wrapper.c:20:
./config.h:206: error: “PACKAGE” redefined [-Werror]
 #define PACKAGE "gas"
...

  gas/config
  *  loongarch-lex-wrapper.c

RISC-V: Add 'Zmmul' extension in assembler.

Three-part patch set from Tsukasa OI to support zmmul in assembler.

The 'Zmmul' is a RISC-V extension consisting of only multiply instructions
(a subset of 'M' which has multiply and divide instructions).

bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Add 'Zmmul' implied by 'M'.
(riscv_supported_std_z_ext): Add 'Zmmul' extension.
(riscv_multi_subset_supports): Add handling for new instruction class.
gas/
* testsuite/gas/riscv/attribute-09.d: Updated implicit 'Zmmul' by 'M'.
* testsuite/gas/riscv/option-arch-02.d: Likewise.
* testsuite/gas/riscv/m-ext.s: New test.
* testsuite/gas/riscv/m-ext-32.d: New test (RV32).
* testsuite/gas/riscv/m-ext-64.d: New test (RV64).
* testsuite/gas/riscv/zmmul-32.d: New expected output.
* testsuite/gas/riscv/zmmul-64.d: Likewise.
* testsuite/gas/riscv/m-ext-fail-xlen-32.d: New test (failure
by using RV64-only instructions in RV32).
* testsuite/gas/riscv/m-ext-fail-xlen-32.l: Likewise.
* testsuite/gas/riscv/m-ext-fail-zmmul-32.d: New failure test
(RV32 + Zmmul but with no M).
* testsuite/gas/riscv/m-ext-fail-zmmul-32.l: Likewise.
* testsuite/gas/riscv/m-ext-fail-zmmul-64.d: New failure test
(RV64 + Zmmul but with no M).
* testsuite/gas/riscv/m-ext-fail-zmmul-64.l: Likewise.
* testsuite/gas/riscv/m-ext-fail-noarch-64.d: New failure test
(no Zmmul or M).
* testsuite/gas/riscv/m-ext-fail-noarch-64.l: Likewise.
include/
* opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZMMUL.
ld/
* testsuite/ld-riscv-elf/attr-merge-arch-01.d: We don't care zmmul in
these testcases, so just replaced m by a.
* testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-arch-01b.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p0.s: Renamed.
* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p1.s: Renamed.
opcodes/
* riscv-opc.c (riscv_opcodes): Updated multiply instructions to zmmul.

[gdb/symtab] Fix assert in set_length

When running the included test-case, we run into:
...
(gdb) break _start^M
read.h:309: internal-error: set_length: \
  Assertion `m_length == length' failed.^M
...

The problem is that while there are two CUs:
...
$ readelf -wi debug-names-missing-cu | grep @
  Compilation Unit @ offset 0x0:
  Compilation Unit @ offset 0x2d:
...
the CU table in the .debug_names section only contains the first one:
...
CU table:
[  0] 0x0
...

The incomplete CU table makes create_cus_from_debug_names_list set the size of
the CU at 0x0 to the actual size of both CUs combined.

This eventually leads to the assert, when we read the actual size from the CU
header.

While having an incomplete CU table in a .debug_names section is incorrect,
we need a better failure mode than asserting.

The easiest way to fix this is to set the length to 0 (meaning: unkown) in
create_cus_from_debug_names_list.

This makes the failure mode to accept the incomplete CU table, but to ignore
the missing CU.

It would be nice to instead reject the .debug_names index, and build a
complete CU list, but the point where we find this out is well after
dwarf2_initialize_objfile, so it looks rather intrusive to restart at that
point.

Tested on x86_64-linux.

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

[gdb/tdep] Declare score-*-* target obsolete

I tried out the script gdb/gdb_mbuild.sh, and ran into:
...
score-elf ...
... configure --target=score-elf
... make score-elf
... run score-elf
score-elf: gdb dumped core
Terminated
...

Gdb runs into this internal error in initialize_current_architecture:
...
  if (! gdbarch_update_p (info))
    internal_error (__FILE__, __LINE__,
                    _("initialize_current_architecture: Selection of "
                      "initial architecture failed"));
...

The call to gdbarch_update_p fails because commit 575b4c298a6 ("gdb: Remove
support for S+core") removed support for the architecture.

Fix this by adding score-*-* to the list of obsolete targets in
gdb/configure.tgt, such that we're no longer able to build the configuration:
...
*** Configuration score-unknown-elf is obsolete.
*** Support has been REMOVED.
make: *** [Makefile:12806: configure-gdb] Error 1
...

Also remove the related line from the "Target Instruction Set Architectures"
list in gdb/MAINTAINERS, such that gdb/gdb_mbuild.sh no longer tries to build
it.

Automatic date update in version.in

Automatic date update in version.in

PR29494 Trailing jump table on ARM

out_inc_line_addr and relax_inc_line_addr are passed INT_MAX as
line_delta to flag end of section.  This filters its way down to
size_inc_line_addr and emit_inc_line_addr.  Pass line_delta on to
scale_addr_delta where it can be used to omit an unaligned opcode
error.

PR 29494
* dwarf2dbg.c (scale_addr_delta): Delete unnecessary forward decl.
Add line_delta param.  Don't print error at end of section, just
round the address down.
(size_inc_line_addr, emit_inc_line_addr): Adjust calls.

Automatic date update in version.in

bfd: Fix minor bug in read_indexed_address function.

read_indexed_address function is using offset_size instead of
addr_size while reading addrx forms.

Automatic date update in version.in

gdbsupport: fix gdb::optional compilation with C++11 && _GLIBCXX_DEBUG

Similar to 911438f9f4 ("gdbsupport: fix array-view compilation with
c++11 && _GLIBCXX_DEBUG"), but for gdb::optional.

I get this error when building with Clang 14 and -std=c++11:

      CXX      agent.o
    In file included from /home/simark/src/binutils-gdb/gdbsupport/agent.cc:20:
    In file included from /home/simark/src/binutils-gdb/gdbsupport/common-defs.h:210:
    In file included from /home/simark/src/binutils-gdb/gdbsupport/common-debug.h:23:
    /home/simark/src/binutils-gdb/gdbsupport/../gdbsupport/gdb_optional.h:213:5: error: use of this statement in a constexpr function is a C++14 extension [-Werror,-Wc++14-extensions]
        gdb_assert (this->has_value ());
        ^
    /home/simark/src/binutils-gdb/gdbsupport/gdb_assert.h:35:3: note: expanded from macro 'gdb_assert'
      ((void) ((expr) ? 0 :                                                       \
      ^

Change-Id: If0cf55607fc9dbd1925ccb97cd9abbf8993ff264

gdb: change bpstat_print's kind parameter to target_waitkind

Change from int to target_waitkind,  which is really what is is.  While
at it, remove some outdated doc.  The return value is described by a
relatively self-describing enum, not a numerical value like the doc
says.

Change-Id: Id899c853a857c7891c45e5b1639024067d5b59cd

gdb, gdbsupport: configure: factor out yes/no/auto value checking

Factor out the code that checks that a value is yes/no or yes/no/auto.
Add two macros to gdbsupport/common.m4 and use them in gdb/configure.ac

I inspected the changes to configure.  Other than whitespace changes, we
have some benign changes to the error messages (one of them had an error
actually).  There are changes to the --enable-source-highlight and
--enable-libbacktrace handling, but setting enable_source_highlight /
enable_libbacktrace was not really useful anyway, they already had the
right value.

Change-Id: I92587aec36874309e1605e2d60244649f09a757a

PR12265, Compiling ld/ fails on Solaris 8

The fail was due to -Werror and headers included by dlfcn.h and
elf-bfd.h disagreeing about AT_DCACHEBSIZE and other AT_*.  Not a
serious problem obviously, since release versions of binutils don't
enable -Werror and the defines are not used.  Anyway, reduce the
number of files that might hit this problem by only including dlfcn.h
where it is needed.

PR 12265
* sysdep.h: Don't include dlfcn.h here.
* plugin.c: Include it here.

Automatic date update in version.in

Allow to document user-defined aliases.

Compared to the previous version, this version fixes the comments reported by
Tom Tromey and ensures that the 'help some-user-documented-alias'
shows the alias definition to ensure the user understands this is an
alias even if specifically documented.

When using 'help ALIASNAME', GDB shows the help of the aliased command.
This is a good default behaviour.

However, GDB alias command allows to define aliases with arguments
possibly changing or tuning significantly the behaviour of
the aliased command.  In such a case, showing the help of the aliased
command might not be ideal.

This is particularly true when defining an alias as a set of
nested 'with' followed by a last command to launch, such as:
  (gdb) alias pp10 = with print pretty -- with print elements 10 -- print
Asking 'help pp10' shows the help of the 'with' command, which is
not particularly useful:
  (gdb) help pp10
  with, pp10, w
    alias pp10 = with print pretty -- with print elements 10 -- print
  Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING.
  Usage: with SETTING [VALUE] [-- COMMAND]
  ....

Such an alias can now be documented by the user:
  (gdb) document pp10
  >Pretty printing an expressiong, printing 10 elements.
  >Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
  >See 'help print' for more information.
  >end
  (gdb) help pp10
    alias pp10 = with print pretty -- with print elements 10 -- print
  Pretty printing an expressiong, printing 10 elements.
  Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
  See 'help print' for more information.
  (gdb)

When a user-defined alias is documented specifically, help and apropos
use the provided alias documentation instead of the documentation of
the aliased command.

Such a documented alias is also not shown anymore in the help of the
aliased command, and the alias is not listed anymore in the help
of the aliased command.  In particular for cases such as pp10 example above,
indicating that pp10 is an alias of the 'with' command is confusing.

sim/aarch64: Fix aarch64_get_CPSR_bits() declaration

Noticed while doing mass builds with a very recent GCC:

/usr/lib/gcc-snapshot/bin/gcc  -DHAVE_CONFIG_H   -DWITH_HW=1 -DHAVE_DV_SOCKSER -DDEFAULT_INLINE=0 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wno-error=maybe-uninitialized -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wmissing-parameter-type -Wpointer-sign -Wold-style-declaration -Werror  -I. -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64 -I../common -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../common -I../../include -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../include -I../../bfd -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../bfd -I../../opcodes -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../opcodes -I../..  -I/var/lib/laminar/run/gdb-aarch64-elf/1/binutils-gdb/sim/aarch64/../../gnulib/import -I../../gnulib/import  -g -O2   -c -o cpustate.o -MT cpustate.o -MMD -MP -MF .deps/cpustate.Tpo cpustate.c
cpustate.c:270:1: error: conflicting types for 'aarch64_get_CPSR_bits' due to enum/integer mismatch; have 'uint32_t(sim_cpu *, FlagMask)' {aka 'unsigned int(struct _sim_cpu *, FlagMask)'} [-Werror=enum-int-mismatch]
  270 | aarch64_get_CPSR_bits (sim_cpu *cpu, FlagMask mask)
      | ^~~~~~~~~~~~~~~~~~~~~
In file included from sim-main.h:30,
                 from cpustate.c:28:
cpustate.h:310:20: note: previous declaration of 'aarch64_get_CPSR_bits' with type 'uint32_t(sim_cpu *, uint32_t)' {aka 'unsigned int(struct _sim_cpu *, unsigned int)'}
  310 | extern uint32_t    aarch64_get_CPSR_bits  (sim_cpu *, uint32_t);
      |                    ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

x86: Ignore protected visibility in shared libraries on Solaris

On x86, the PLT entry in executable may be used as function address for
functions in shared libraries.  If functions are protected, the function
address used in executable can be different from the function address
used in shared library.  This will lead to incorrect run-time behavior
if function pointer equality is needed.  By default, x86 linker issues
an error in this case.

On Solaris, linker issued an error for

struct tm *tb = (kind == CPP_time_kind::FIXED ? gmtime : localtime) (&tt);

where gmtime is a protected function in libc.so.  Use gmtime's PLT entry
in executable as function address is safe since function pointer equality
isn't needed.  Ignore protected visibility in shared libraries on Solaris
to disable linker error.  If function pointer equality is needed, linker
will silently generate executable with incorrect run-time behavior on
Solaris.

PR ld/29512
* elf32-i386.c (elf_i386_scan_relocs): Ignore protected
visibility in shared libraries on Solaris.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.

GAS: Add a return type tag to DWARF DIEs generated for function symbols.

PR 29517
* dwarf2dbg.c (GAS_ABBREV_COMP_UNIT): New defined constant.
(GAS_ABBREV_SUBPROG): New defined constant.
(GAS_ABBREV_NO_TYPE): New defined constant.
(out_debug_abbrev): Use the new defined constants when emitting
abbreviation numbers.  Generate an abbreviation for an unspecified
type.
(out_debug_info): Use the new defined constants when referring to
abbreviations.  Generate a use of the no_type abbreviation.
Reference the use when generating DIEs for functions.
* testsuite/gas/elf/dwarf-3-func.d: Update to allow for newly
extended output from the assembler.
* testsuite/gas/elf/dwarf-5-func-global.d: Likewise.
* testsuite/gas/elf/dwarf-5-func-local.d: Likewise.
* testsuite/gas/elf/dwarf-5-func.d: Likewise.

GAS: Allow AArch64 pseudo-ops to accept the command line separator character.

PR 29519
* config/tc-aarch64.c (s_unreq): Use find_end_of_line().
(s_aarch64_cpu): Likewise.
(s_aarch64_arch): Likewise.
(s_aarch64_arch_extension): Likewise.
* testsuite/gas/aarch64/pr29519.d: New test driver file.
* testsuite/gas/aarch64/pr29519.s: New test source file.

gas: NEWS: Add the RISC-V features for 2.39

gas: NEWS: Add the RISC-V features for 2.38

gas: NEWS: Add the RISC-V features for 2.37

gas: NEWS: Add the RISC-V features for 2.36

gas: NEWS: Add the RISC-V features for 2.35

gas: NEWS: Add the RISC-V features for 2.31

PR11290, avr-ld "out of range error" is confusing

Don't overload bfd_reloc_outofrange with what is really a domain error
(target at odd address), or an overflow.

PR 11290
* reloc.c (bfd_reloc_other): Correct comment.
* elf32-avr.c (avr_final_link_relocate): Return bfd_reloc_other
for unaligned reloc target values.  Return bfd_reloc_overflow
when stubs are too far away and when R_AVR_LDS_STS_16,
R_AVR_PORT6, or R_AVR_PORT5 overflow.
(elf32_avr_relocate_section): Report more descriptive relocation
errors.
* bfd-in2.h: Regenerate.

ld: pe: Move the return type to a separate line from the function name

This fixes the coding style of an old, preexisting function.

PR10372, SH: ld test with sim/sh/run fails always

PR 10372
* testsuite/ld-sh/start.s: Add _start sym.  Use trapa 34.  Create
an alloc .stack section.

Re: LoongArch: ld: Fix bug not generate plt when link a dso

Fixes loongarch32-elf  +FAIL: medium jirl plt

* testsuite/ld-loongarch-elf/cmodel.exp: Don't run test when
no shared library support.

Automatic date update in version.in

ld: pe: Make archive member file extension comparisons case insensitive when cross compiling too

On Windows, filename_cmp is case insensitive, but when cross compiling
with libraries that may contain members with uppercase file names, we
should keep those comparisons case insensitive when running the build
tools on other OSes too.

Also make the check for .def consistent with the other ones, fixing
out of bounds reads if file names are shorter than 4 characters.

gas: arm: handle multiple .directives on a single line (PR29519)

There's been a long-standing bug in the arm backend where
target-specific directives did not correctly handle lines with
multiple statements.  This patch fixes the issue for all the cases
I've been able to find.

It does result in a slight change in behaviour when errors are
encountered: where, previously,

  .cpu arm6 bar

would result in the error "junk at end of line, first unrecognized
character is `b'", we now get "unknown cpu `arm6 bar'", which I think
is slightly more helpful anyway.  Similar errors are generated for
other directives.

gdb: new 'maint print frame-id' command

When debugging a certain class of GDB bug, I often end up wanting to
know what GDB thinks the frame-id is in a particular frame.  It's
not too hard to pull this from some debug output, but I thought it
might be nice if there was a maintenance command that could tell us.

This commit adds 'maint print frame-id' which prints the frame-id of
the currently selected frame.  You can also pass a frame level number
to find the frame-id for a specific frame.

There's a new test too.

LoongArch: ld: Fix bug not generate plt when link a dso

  Fix the bug that can not generate func@plt
  when linking a undefined function with cmodel=medium.
  Add testcase.

  bfd/
    * elfnn-loongarch.c
  ld/testsuite/ld-loongarch-elf/
    * cmodel-libjirl.dd
    * cmodel.exp
    * libjirl.s

Automatic date update in version.in

SHT_RELR sh_link and sh_info

I don't think it makes any sense for a SHT_RELR section to specify a
symbol table with sh_link.  SHT_RELR relocations don't use symbols.
There is no real need to specify sh_info either, SHT_RELR is not for
relocatable object files.  Anyway, fuzzers of course don't restrict
themselves to even half-sensible objects.  So they found a hole in
objcopy using a non-alloc SHT_RELR in an ET_EXEC.  In that case BFD
set up the SHT_RELR section as if it were a SHT_REL against the
sh_info target section.  When it came to reading in the target section
relocs, the count was horribly wrong which caused a buffer overflow.

* elf.c (bfd_section_from_shdr <SHT_RELR>): Always just make a
normal section, don't treat it as a reloc section.

Re: bfd_elf_set_group_contents assertion

Further to commit 7744e3278b9f.

* elf.c (bfd_elf_set_group_contents): Restrict loc in loop writing
contents, and add another assertion.

Add an option to dlltool to allow the creation of deterministic libraries.

PR 29489
* dlltool.c (deterministic): New variable.
(gen_lib_file): If deterministic is true set the
BFD_DETERMINISTIC_OUTPUT flag.
(usage): Mention --deterministic-libraries and
--non-deterministic-libraries.
(long_options): Add new options.
(main): Parse new options.
* doc/binutils.texi: Document the new options.
* NEWS: Mention the new feature.

binutils: Updated my email address.

binutils/
    * MAINTAINERS (RISC-V): Updated my email address.

Automatic date update in version.in

Implement target async for Windows

This implements target async for Windows.  The basic idea is to have
the worker thread block in WaitForDebugEvent, then notify the event
loop when an event is seen.  In a few situations, this blocking
behavior is undesirable, so the functions passed to do_synchronously
are changed to return a boolean indicating which behavior is needed.

Move some Windows operations to worker thread

On Windows, certain debugging APIs can only be called from the thread
that started (or attached) to the inferior.  Also, there is no way on
Windows to wait for a debug event in addition to other events.
Therefore, in order to implement target async for Windows, gdb will
have to call some functions in a worker thread.

This patch implements the worker thread and moves the necessary
operations there.  Target async isn't yet implemented, so this patch
does not cause any visible changes.

Avoid crash with Ravenscar tasks

When using Ravenscar, gdb can crash if the user sets a breakpoint very
early in task startup.  This happens because gdb thinks the runtime is
initialized, but in practice the particular task isn't sufficiently
initialized.  This patch avoids the issue by turning an assertion into
an early return.

I tested this using the AdaCore internal test suite.  I don't know how
to test Ravenscar using the FSF test suite.

Fix compile time warning from Clang about error messages not being printed safely.

Have readelf warn users if it is asked to decode a LLVM bitcode file or a golang object file.

* readelf.c (check_magic_number): New function.  Checks the magic
bytes at the start of a file.  If they are not the ELF format
magic values, then attempts to generate a helpful error message.
(process_file_header): Call check_magic_number.

Add OpenBSD AArch64 Little Endian BFD support.

* config.bfd (aarch64-*-openbsd*): Add target.

LoongArch: gas: add support using constant variable in instructions.

        Instructions that can load immediate support using constant
        variable like ".equ var, 123    li.w/d resgister, var".

gas/
        * config/loongarch-parse.y
        * config/tc-loongarch.c

        Add four testcases.One is a program using constant variable,
        one test using label is unsupported, and another two test
        almost instructions that can load immediate.

gas/
        * testsuite/gas/loongarch/li.d
        * testsuite/gas/loongarch/li.s
        * testsuite/gas/loongarch/imm_ins_label-fail.d
        * testsuite/gas/loongarch/imm_ins_label-fail.l
        * testsuite/gas/loongarch/imm_ins_label-fail.s
        * testsuite/gas/loongarch/imm_ins.d
        * testsuite/gas/loongarch/imm_ins.s
        * testsuite/gas/loongarch/imm_ins_32.d
        * testsuite/gas/loongarch/imm_ins_32.s

Automatic date update in version.in

Fix crash in gdbpy_parse_register_id

I noticed that gdbpy_parse_register_id would assert if passed a Python
object of a type it was not expecting.  The included test case shows
this crash.  This patch fixes the problem and also changes
gdbpy_parse_register_id to be more "Python-like" -- it always ensures
the Python error is set when it fails, and the callers now simply
propagate the existing exception.

Automatic date update in version.in

symbols for bfd_simple_get_relocated_section_contents

If symbols are provided by the caller of this function they are
passed on to bfd_get_relocated_section_contents.  No surprises there.
It gets a little weird if they are not provided.  In that case they
are read from the bfd by _bfd_generic_link_add_symbols, and global
symbols are added to the generic linker hash table.  Global symbols
are not added to the linker hash table if symbols *are* provided.  Now
the linker hash table symbols are not used by the generic
bfd_get_relocated_section_conents, and also not by most target
versions when called from bfd_simple_get_relocated_section_contents
except for symbols like "_gp".  So it mostly doesn't matter whether
symbols are in the linker hash table, but it's odd that there is a
difference.  We could always add them, but I'm inclined to think that
is unnecessary work so this patch always leaves them out.

Also, symbols are canonicalized and written into a malloc'd buffer.
The buffer isn't freed, see commit 8e16317ca5eb.  I don't know whether
that matters any more, but in any case I can't see why we need another
copy of the symbols when _bfd_generic_link_read_symbols has already
cached symbols.

* simple.c (bfd_simple_get_relocated_section_contents): If not
provided, read symbols via bfd_generic_link_read_symbols.  Do
not create another copy of symbols.  Tidy failure exits.
Minor tidy of bfd_get_relocated_section_contents and
bfd_get_full_section_contents arguments.

Re: Missing linking test case for pe dll using a def file

Fixes this when cross-compiling from x86_64-linux
x86_64-w64-mingw32  +FAIL: compiling shared lib fastcall/stdcall

* testsuite/ld-pe/pe-run2-def.exp (test_direct2_link_dll_def):
Use CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.

Automatic date update in version.in

gdb_do_one_event: use integer test syntax

Timeout is an int, not a bool.

Remove two initialization functions

I noticed a couple of initialization functions that aren't really
needed, and that currently require explicit calls in gdb_init.  This
patch removes these functions, simplifying gdb a little.

Regression tested on x86-64 Fedora 34.

gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE

As Luis pointed out here [1], the AArch64 variant of the test doesn't
work on systems that use PIE by default.  For example, on this Debian
11:

    $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp"
    gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC
    /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4'

This is because entry-value-typedef-aarch64.S was generated on an old
system that does not generate position-independent code by default, but
the system the test runs on tries to link the test executable as
position-independent.  Fix this by regenerating the same binary on the
same system as the original one, but with -fPIE this time.  Do the same
for the amd64 binary, although this one was already position-independent
so the generated code doesn't change.

With this patch applied, the test passes on the Debian 11 AArch64
system.

[1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html

Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144

gdb, testsuite: Adapt gdb.base/callfuncs.exp for new clang warning.

Clang 15.0.0 enabled the warning for deprecated non-prototype functions
by default: https://reviews.llvm.org/D122895
Callfuncs.exp is impacted and won't run due to new warnings:

callfuncs.c:339:5: warning: a function declaration without a prototype is
deprecated in all versions of C and is not supported in C2x
[-Wdeprecated-non-prototype]
int t_float_values (float_arg1, float_arg2)

This patch disables those warnings with -Wno-deprecated-non-prototype.
Removing the test for deprecated syntax would also be an option. But I will
leave that up for others to decide/implement.

gdb, testsuite: Enable testcases that suppress specific warnings, for icc/icx.

To cite gdb.exp:
Some C/C++ testcases unconditionally pass -Wno-foo as additional
options to disable some warning.  That is OK with GCC, because
by design, GCC accepts any -Wno-foo option, even if it doesn't
support -Wfoo.  Clang however warns about unknown -Wno-foo by
default, unless you pass -Wno-unknown-warning-option as well.
We do that here, so that individual testcases don't have to
worry about it.

This patch adds the same option that already exists for clang for icx and
adds the equivalent icc option.

gdb: LoongArch: Handle variadic arguments

According to LoongArch ELF ABI specification [1], variadic arguments
are passed in GARs in the same manner as named arguments. And after
a variadic argument has been passed on the stack, all future arguments
will also be passed on the stack, i.e., the last argument register may
be left unused due to the aligned register pair rule. long double data
tpye is passed in an aligned GAR pair, the first register in the pair
is even-numbered.

[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

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

loongarch64_pei_vec garbage in objcopy'd relocs

Like commit a9c09a3667cc, but for loongarch64.

* coff-loongarch64.c (SWAP_IN_RELOC_OFFSET): Define.
(SWAP_OUT_RELOC_OFFSET): Define.

Automatic date update in version.in

gprofng: fix bug 29479 Collection fails when built without java support

gprofng/ChangeLog
2022-08-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29479
* libcollector/collector.c: Add #if defined(GPROFNG_JAVA_PROFILING) for
java specific code.
* libcollector/unwind.c: Likewise.

gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result

Bug 29374 shows this crash:

    $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out
    ...
    /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.

The backtrace is:

    #0  internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51
    #1  0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217
    #2  0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040
    #3  0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091
    #4  0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485
    #5  0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529
    #6  0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235
    #7  0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332
    #8  0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365
    #9  0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889
    #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559
    #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887
    #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390
    #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116
    #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079
    #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198

The problem is that the type that gets passed down to
dwarf_expr_context::fetch_result (the type of a variable of which we're
trying to read the entry value) is a typedef whose size has never been
computed yet (check_typedef has never been called on it).  As we get in
the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len`
variable is therefore set to 0, instead of the actual type length.  We
then call allocate_value on subobj_type, which does call check_typedef,
so the length of the typedef gets filled in at that point.  We end up
passing to the copy function a source array view of length 0 and a
target array view of length 4, and the assertion fails.

Fix this by calling check_typedef on both type and subobj_type at the
beginning of fetch_result.

I tried writing a test for this using the DWARF assembler, but I haven't
succeeded.  It's possible that we need to get into this specific code
path (value_of_dwarf_reg_entry and all) to manage to get to
dwarf_expr_context::fetch_result with a typedef type that has never been
resolved.  In all my attempts, the typedef would always be resolved
already, so the bug wouldn't show up.

As a fallback, I made a gdb.dwarf2 test with compiler-generated .S
files.  I don't particularly like those, but I think it's better than no
test.  The .cpp source code is the smallest reproducer I am able to make
from the reproducer given in the bug (thanks to Pedro for suggestions on
how to minimize it further than I had).  Since I tested on both amd64
and aarch64, I added versions of the test for these two architectures.

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

[aarch64] Remove handling of ADR/ADRP from prologue analyzer

As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html,
the aarch64 prologue analyzer considers the adrp instruction in the
gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue.

The function has no prologue though, and it only loads the volatile variable
from memory.  GDB should not skip any instructions in this case.

Doing some archaeology, it seems handling for adr/adrp in prologues was
included with the original aarch64 port.  It might've been an oversight.

In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips
a couple instructions and leaves us in a nice spot where the address to the
variable "v" is already in w0. But no prologues exists.

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

Change bookmark allocation

This changes how bookmarks are allocated and stored, replacing a
linked list with a vector and removing some ALL_* iterator macros.
Regression tested on x86-64 Fedora 34.