[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.

Add test for AArch64 Scalable Vector Extension

It exercises a bug that GDB previously had where it would lose track of
some registers when the inferior changed its vector length.

It also checks that the vg register and the size of the z0-z31 registers
correctly reflect the new vector length.

Fix thread's gdbarch when SVE vector length changes

When the inferior program changes the SVE length, GDB can stop tracking
some registers as it obtains the new gdbarch that corresponds to the
updated length:

  Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44
  44              res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0);
  (gdb) print i
  $2 = 32
  (gdb) info registers
          ⋮
  [ snip registers x0 to x30 ]
          ⋮
  sp             0xffffffffeff0      0xffffffffeff0
  pc             0xaaaaaaaaa8ac      0xaaaaaaaaa8ac <do_sve_ioctl_test+112>
  cpsr           0x60000000          [ EL=0 BTYPE=0 C Z ]
  fpsr           0x0                 0
  fpcr           0x0                 0
  vg             0x8                 8
  tpidr          0xfffff7fcb320      0xfffff7fcb320
  (gdb) next
  45              if (res < 0) {
  (gdb) info registers
          ⋮
  [ snip registers x0 to x30 ]
          ⋮
  sp             0xffffffffeff0      0xffffffffeff0
  pc             0xaaaaaaaaa8cc      0xaaaaaaaaa8cc <do_sve_ioctl_test+144>
  cpsr           0x200000            [ EL=0 BTYPE=0 SS ]
  fpsr           0x0                 0
  fpcr           0x0                 0
  vg             0x4                 4
  (gdb)

Notice that register tpidr disappeared when vg (which holds the vector
length) changed from 8 to 4.  The tpidr register is provided by the
org.gnu.gdb.aarch64.tls feature.

This happens because the code that searches for a new gdbarch to match the
new vector length in aarch64_linux_nat_target::thread_architecture doesn't
take into account the features present in the target description associated
with the previous gdbarch.  This patch makes it do that.

Since the id member of struct gdbarch_info is now unused, it's removed.

Missing linking test case for pe dll using a def file.

PR 28362
* testsuite/ld-pe/pe-run2-def.exp: New file.

gdbsupport/event-loop: add a timeout parameter to gdb_do_one_event

Since commit b2d8657, having a per-interpreter event/command loop is not
possible anymore.

As Insight uses a GUI that has its own event loop, gdb and GUI event
loops have then to be "merged" (i.e.: work together). But this is
problematic as gdb_do_one_event is not aware of this alternate event
loop and thus may wait forever.

A solution is to delegate GUI events handling to the gdb events handler.
Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to
implement such a delegation. The Tcl notifier spec requires the event wait
function to support a timeout parameter. Unfortunately gdb_do_one_event
does not feature such a parameter.
This timeout cannot be implemented externally with a gdb timer, because
it would become an event by itself and thus can cause a legitimate event to
be missed if the timeout is 0.
Tcl implements "idle events" that are (internally) triggered only when no
other event is pending. For this reason, it can call the event wait function
with a 0 timeout quite often.

This patch implements a wait timeout to gdb_do_one_event. The initial
pending events monitoring is performed as before without the possibility
to enter a wait state. If no pending event has been found during this
phase, a timer is then created for the given timeout in order to re-use
the implemented timeout logic and the event wait is then performed.
This "internal" timer only limits the wait time and should never be triggered.
It is deleted upon gdb_do_one_event exit.

The new parameter defaults to "no timeout" (-1): as it is used by Insight
only, there is no need to update calls from the gdb source tree.

gdb: add Patrick Monnerat to gdb/MAINTAINERS

x86: move / quiesce pre-386 non-16-bit warning

Emitting this warning for every insn, including ones having actual
errors, is annoying. Introduce a boolean variable to emit the warning
just once on the first insn after .arch may have changed the things, and
move the warning to output_insn(). (I didn't want to go as far as
checking whether the .arch actually turned off the i386 bit, but doing
so would be an option.)

x86: insert "no error" enumerator in i386_error enumeration

The value of zero would better not indicate any error, but rather hit
the abort() at the top of the consuming switch().

Automatic date update in version.in

GDB/testsuite: Fix PARAM_ZUINTEGER reported for PARAM_ZUINTEGER_UNLIMITED

Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER
in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.

bfd_elf_set_group_contents assertion

objcopy of broken SHT_GROUP sections shouldn't write garbage.

* elf.c (bfd_elf_set_group_contents): If number of entries is
unexpected, fill out section with zeros.

timeout in mmo_get_symbols

Fix mmo_get_byte to return a fail-safe value, not just on the first
call with a read error but on subsequent calls too.

* mmo.c (mmo_get_byte): Return the fail-safe value on every
call after a read error.

mmo.c leak in mmo_make_section

* mmo.c (mmo_make_section): Alloc name using bfd_alloc.  Use
bfd_error_no_memory.
(mmo_decide_section): Check for NULL return from mmo_make_section.

asan: heap buffer overflow in mmo_scan

mmo_get_loc needs to handle arbitrary vma and size chunks.  Fuzzers
found that it wasn't working so well when the end of chunks were
getting close to address wrap-around.

* mmo.c (mmo_get_loc): Make "size" unsigned.  Avoid arithmetic
overflow when calculating whether range hits an existing chunk.

elf.c tidy

Swap params of is_note, so they are section, segment like others used
in rewrite_elf_program_header.  Whitespace fixes, plus wrapping of
overlong lines.

Automatic date update in version.in

bfd: Define ___lc_codepage_func prototype for older MinGW-w64

In commit 68e80d96a84282d547f3b3c1234c99009521630c, the usage of
___lc_codepage_func was introduced to determine the current encoding.

Prior to version 9.0 of MinGW-w64, the function prototype for
___lc_codepage_func was missing and trying to build BFD caused the
following error:

error: implicit declaration of function ‘___lc_codepage_func’

This changeset adds a conditonal definition of
___lc_codepage_func to allow a sucessful build with MinGW-w64.

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

i386: Add MAX_OPERAND_BUFFER_SIZE

When displaying operands, invalid opcodes may overflow operand buffer
due to additional styling characters.  Each style is encoded with 3
bytes.  Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and
increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles
in an operand.

gas/

PR binutils/29483
* testsuite/gas/i386/i386.exp: Run pr29483.
* testsuite/gas/i386/pr29483.d: New file.
* testsuite/gas/i386/pr29483.s: Likewise.

opcodes/

PR binutils/29483
* i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New.
(obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE.
(staging_area): Likewise.
(op_out): Likewise.

gdb/riscv: fix gdb.arch/riscv-unwind-long-insn.exp on RV64

I noticed that the gdb.arch/riscv-unwind-long-insn.exp test was
failing when run on a 64-bit RISC-V target.

The problem was that GDB was failing to stop after a finish command,
and was then running to an unexpected location.

The reason GDB failed to stop at the finish breakpoint was that the
frame-id of the inferior, when we reached the finish breakpoint,
didn't match the expected frame-id that was stored on the breakpoint.

The reason for this mismatch was that the assembler code that is
included in this test, was written only taking 32-bit RISC-V into
account, as a result, the $fp register was being corrupted, and this
was causing the frame-id mismatch.

Specifically, the $fp register would end up being sign-extended from
32 to 64 bits.  If the expected $fp value has some significant bits
above bit 31 then the computed and expected frame-ids would not match.

To fix this I propose merging the two .s files into a single .S file,
and making use of preprocessor macros to specialise the file for the
correct size of $fp.  There are plenty of existing tests that already
make use of preprocessor macros in assembler files, so I assume this
approach is fine.

Once I'd decided to make use of preprocessor macros to solve the 32/64
bit issue, then I figured I might as well merge the two test assembler
files, they only differed by a single instruction.

With this change in place I now see this test fully passing on 32 and
64 bit RISC-V targets.

gdb/testsuite: fix breakpoint script output in gdb.mi/mi-break.exp

Commit 9db0d8536dbc ("gdb/mi: fix breakpoint script field output") fixed
the output of the script key in the MI breakpoint output, from

  script={"print 10","continue"}

to

  script=["print 10","continue"]

However, it missed updating this test case, which still tests for the
old (broken) form, causing:

    FAIL: gdb.mi/mi-break.exp: mi-mode=main: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
    FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)

Update the test to expect the new form.

Change-Id: I174919d4eea53e96d914ca9bd1cf6f01c8de30b8

Use strwinerror in gdb/windows-nat.c

When working on windows-nat.c, it's useful to see an error message in
addition to the error number given by GetLastError.  This patch moves
strwinerror from gdbserver to gdbsupport, and then updates
windows-nat.c to use it.  A couple of minor changes to strwinerror
(constify the return type and use the ARRAY_SIZE macro) are also
included.

Remove register_gdbarch_init

This removes the deprecated register_gdbarch_init in favor a default
argument to gdbarch_register.  Regression tested on x86-64 Fedora 34.

PR29495, rewrite_elf_program_header looping

This patch, in order of significance:
1) Replaces some macros with inline functions.
2) Those inline functions catch and avoid arithmetic overflows when
   comparing addresses.
3) When assigning sections to segments (IS_SECTION_IN_INPUT_SEGMENT)
   use bed->want_p_paddr_set_to_zero to decide whether lma vs p_paddr
   or vma vs p_vaddr should be tested.  When remapping, use the same
   test, and use is_note rather than the more restrictive
   IS_COREFILE_NOTE.

It's important that the later tests not be more restrictive.  If they
are it can lead to the situation triggered by the testcases, where a
section seemingly didn't fit and thus needed a new mapping.  It didn't
fit the new mapping either, and this repeated until memory exhausted.

PR 29495
* elf.c (SEGMENT_END, SECTION_SIZE, IS_CONTAINED_BY_VMA): Delete.
(IS_CONTAINED_BY_LMA, IS_NOTE, IS_COREFILE_NOTE): Delete.
(segment_size, segment_end, section_size): New inline function.
(is_contained_by, is_note): Likewise.
(rewrite_elf_program_header): Use new functions.

x86: shorten certain template names

Now that we can purge templates, let's use this to improve readability a
little by shortening a few of their names, making functionally similar
ones also have identical names in their multiple incarnations.

x86: template-ize certain vector conversion insns

Many of the vector conversion insns come with X/Y/Z suffixed forms, for
disambiguation purposes in AT&T syntax. All of these gorups follow
certain patterns. Introduce "xy" and "xyz" templates to reduce
redundancy.

To facilitate using a uniform name for both AVX and AVX512, further
introduce a means to purge a previously defined template: A standalone
<name> will be recognized to have this effect.

Note that in the course of the conversion VFPCLASSPH is properly split
to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D} and
yielding the intended "ambiguous operand size" diagnostic in Intel mode.

x86: template-ize vector packed byte/word integer insns

Many of the vector integer insns come in byte/word element pairs. Most
of these pairs follow certain encoding patterns. Introduce a "bw"
template to reduce redundancy.

Note that in the course of the conversion
- the AVX VPEXTRW template which is not being touched needs to remain
  ahead of the new "combined" ones, as (a) this should be tried first
  when matching insns against templates and (b) its Load attributes
  requires it to be first,
- this add a benign/meaningless IgnoreSize attribute to the memory form
  of PEXTRB; it didn't seem worth avoiding this.

x86: re-order AVX512 S/G templates

The AVX2 gather ones are nicely grouped - do the same for the various
AVX512 scatter/gather ones. On the moved lines also convert EVex=<n> to
EVex<N>.

x86: template-ize vector packed dword/qword integer insns

Many of the vector integer insns come in dword/qword element pairs. Most
of these pairs follow certain encoding patterns. Introduce a "dq"
template to reduce redundancy.

Note that in the course of the conversion
- a few otherwise untouched templates are moved, so they end up next to
  their siblings),
- drop an unhelpful Cpu64 from the GPR form of VPBROADCASTQ, matching
  what we already have for KMOVQ - the diagnostic is better this way for
  insns with multiple forms (i.e. the same Cpu64 attributes on {,V}MOVQ,
  {,V}PEXTRQ, and  {,V}PINSRQ are useful to keep),
- this adds benign/meaningless IgnoreSize attributes to the GPR forms of
  KMOVD and VPBROADCASTD; it didn't seem worth avoiding this.

x86: template-ize packed/scalar vector floating point insns

The vast majority of vector FP insns comes in single/double pairs. Many
pairs follow certain encoding patterns. Introduce an "sd" template to
reduce redundancy. Similarly, to further cover similarities between
AVX512F and AVX512-FP16, introduce an "sdh" template.

For element-size Disp8 shift generalize i386-gen's broadcast size
determination, allowing Disp8MemShift to be specified without an operand
in the affected templated templates. While doing the adjustment also
eliminate an unhelpful (lost information) diagnostic combined with a use
after free in what is now get_element_size().

Note that in the course of the conversion
- the AVX512F form of VMOVUPD has a stray (leftover) Load attribute
  dropped,
- VMOVSH has a benign IgnoreSize added (the attribute is still strictly
  necessary for VMOVSD, and necessary for VMOVSS as long as we permit
  strange combinations like "-march=i286+avx"),
- VFPCLASSPH is properly split to separate AT&T and Intel syntax forms,
  matching VFPCLASSP{S,D}.

revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"

This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which
broke i386-gen's emitting of diagnostics. As a replacement to address
the original issue of newer gcc no longer splicing lines when dropping
the line continuation backslashes, switch to using + as the line
continuation character, doing the line splicing in i386-gen.

Automatic date update in version.in

PR29362, some binutils memory leaks

2022-08-16  Alan Modra  <amodra@gmail.com>
    Cunlong Li  <shenxiaogll@163.com>

PR 29362
* dwarf.c (free_debug_information): New function, extracted..
(free_debug_memory): ..from here.
(process_debug_info): Use it when before clearing out unit
debug_information.  Clear all fields.
* objcopy.c (delete_symbol_htabs): New function.
(main): Call it via xatexit.
(copy_archive): Free "dir".
* objdump.c (free_debug_section): Free reloc_info.

gdb/csky add unwinder for sigtramp frame when kernel 4.x and later

When kernel veriosn >= V4.x, the characteristic values used to
determine whether it is a signal function call are:
    movi r7, 139
    trap 0

Registers are saved at (sp + CSKY_SIGINFO_OFFSET + CSKY_SIGINFO_SIZE
+ CSKY_UCONTEXT_SIGCONTEXT + CSKY_SIGCONTEXT_PT_REGS_TLS). The order
is described in csky_linux_rt_sigreturn_init_pt_regs.

aarch64_pei_vec

I know this target is just a skeleton, but let's not write out relocs
with uninitialised garbage.

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

Automatic date update in version.in

gdb/riscv: improve a comment about fcsr, fflags, and frm registers

There's a comment in riscv-tdep.c that explains some of the background
about how we check for the fcsr, fflags, and frm registers within a
riscv target description.

This comment (and the functionality it describes) relates to how QEMU
advertises these registers within its target description.

Unfortunately, QEMU includes these three registers in both the fpu and
crs target description features.  To work around this GDB uses one of
the register declarations, and ignores the other, this means the GDB
user sees a single copy of each register, and things just work.

When I originally wrote the comment I thought it didn't matter which
copy of the register GDB selected, the fpu copy or the csr copy, so
long as we just used one of them.  The comment reflected this belief.

Upon further investigation, it turns out I was wrong.  GDB has to use
the csr copy of the register.  If GDB tries to use the register from
the fpu feature then QEMU will return an error when GDB tries to read
or write the register.

Luckily, the code within GDB (currently) will always select the csr
copy of the register, so nothing is broken, but the comment is wrong.
This commit updates the comment to better describe what is actually
going on.

Of course, I should probably also send a patch to QEMU to fix up the
target description that is sent to GDB.

gdb/nds32: update features/nds32.c

After this commit:

  commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921
  Date:   Wed Sep 15 10:10:46 2021 +0200

      [bfd] Ensure unique printable names for bfd archs

The printable name field of the default nds32 bfd_arch_info changed
from 'n1h' to 'n1'.  As a consequence the generated feature file
within GDB should have been recreated.  Recreate it now.

Move decode_location_spec to code_breakpoint

breakpoint::decode_location_spec just asserts if called.  It turned
out to be relatively easy to remove this method from breakpoint and
instead move the base implementation to code_breakpoint.