bfd: remove use of INLINE

No need to use anything fancy, plain inline works just as well.

* bfd-in.h (INLINE): Don't define.
* bfd-in2.h: Regenerate.
* aoutx.h: Replace use of INLINE with inline.
* elf-eh-frame.c: Likewise.
* elf32-score7.c: Likewise.
* elfxx-mips.c: Likewise.
* ihex.c: Likewise.
* mach-o.c: Likewise.
* mmo.c: Likewise.

ASSERT in empty output section with address

* ldlang.c (lang_do_assignments_1): Correct "dot" inside ignored
sections.
* testsuite/ld-scripts/empty-address-4.d,
* testsuite/ld-scripts/empty-address-4.s,
* testsuite/ld-scripts/empty-address-4.t: New test.
* testsuite/ld-scripts/empty-address.exp: Run it.

Automatic date update in version.in

asan: alpha-vms: buffer overflows

Yet more anti-fuzzer sanity checking

* vms-alpha.c (evax_bfd_print_egsd): Sanity check record and
name lengths before access.
(evax_bfd_print_etir_stc_ir, evax_bfd_print_etir): Likewise.

ubsan: arm: undefined shift

left shift of 2 by 31 places cannot be represented in type 'int'

* arm-dis.c (print_insn_thumb16): Avoid undefined behaviour.

Fix watchpoints with multiple threads on Windows

A recent internal change pointed out that watchpoints were not working
on Windows when the inferior was multi-threaded.  This happened
because the debug registers were only updated for certain threads --
in particular, those that were being resumed and that were not marked
as suspended.  In the case of single-stepping, the need to update the
debug registers in other threads could also be "forgotten".

This patch changes windows-nat.c to mark all threads needing a debug
register update.  This brings the code closer to what gdbserver does
(though, unfortunately, it still seems more complicated than needed).

[gdb/testsuite] Fix port detection in gdb.debuginfod/fetch_src_and_symbols.exp

On OBS I ran into this failure with test-case
gdb.debuginfod/fetch_src_and_symbols.exp:
...
Failed to listen for connections: Address already in use^M
[Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M
  ...
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout
...

The test-case is trying to start debuginfod on a port to see if it's
available, and it handles either this message:
  "started http server on IPv4 IPv6 port=$port"
meaning success, or:
  "failed to bind to port"
meaning failure, in which case the debuginfod instance is killed, and we try
the next port.

The test-case only uses the v4 address 127.0.0.1, so fix this by:
- accepting "started http server on IPv4 port=$port"
- rejecting "started http server on IPv6 port=$port"

Tested on x86_64-linux.

gdb: fix value.c build on 32-bits

When building on ARM (32-bits), we errors like this:

    /home/smarchi/src/binutils-gdb/gdb/value.c: In function 'gdb::array_view<const unsigned char> value_contents_for_printing(value*)':
    /home/smarchi/src/binutils-gdb/gdb/value.c:1252:35: error: narrowing conversion of 'length' from 'ULONGEST' {aka 'long long unsigned int'} to 'size_t' {aka 'unsigned int'} [-Werror=narrowing]
     1252 |   return {value->contents.get (), length};
          |                                   ^~~~~~

Fix that by using gdb::make_array_view, which does the appropriate
conversion.

Change-Id: I7d6f2e75d7440d248b8fb18f8272ee92954b404d

RISC-V: Tidy riscv assembler and disassembler.

Tidy the gas/config/tc-riscv.c and opcodes/riscv-dis.c, to prepare for
moving the released extensions (including released vendor extensions)
from integration branch back to mainline.

* Added parts of missing comments.

* Updated md_show_usage.

* For validate_riscv_insn, riscv_ip and print_insn_args, unify the
  following pointer names,
  - oparg: pointed to the parsed operand defined in the riscv_opcodes.
  - asarg: pointed to the parsed operand from assembly.
  - opargStart: recorded the parsed operand name from riscv_opcodes.
  - asargStart: recorded the parsed operand name from assembly.

gas/
* config/tc-riscv.c: Added parts of missind comments and updated
the md_show_usage.
(riscv_multi_subset_supports): Tidy codes.
(validate_riscv_insn): Unify the pointer names, oparg, asarg,
opargStart and asargStart, to prepare for moving the released
extensions from integration branch back to mainline.
(riscv_ip): Likewise.
(macro_build): Added fmtStart, also used to prepare for moving
released extensions.
(md_show_usage): Added missing descriptions for new options.
opcodes/
* riscv-dis.c (print_insn_args): Unify the pointer names,
oparg and opargStart, to prepare for moving the released
extensions from integration branch back to mainline.

opcodes: Fix RPATH not being set for dynamic libbfd dependency

If built as a shared library, libopcodes has a load-time dependency on
libbfd, which is recorded in the dynamic section, however without a
corresponding RPATH entry for the directory to find libbfd in.  This
causes loading to fail whenever libbfd is only pulled by libopcodes
indirectly and libbfd has been installed in a directory that is not in
the dynamic loader's search path.

It does not happen with the programs included with binutils or GDB,
because they all also pull libbfd when using libopcodes, but it can
happen with external software, e.g.:

$ gdbserver --help
gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory
$

(not our `gdbserver').

Indirect dynamic dependencies are handled by libtool automatically by
adding RPATH entries as required, however our setup for libopcodes
prevents this from happening by linking in libbfd with an explicit file
reference sneaked through to the linker directly behind libtool's back
via the `-Wl' linker command-line option rather than via `-l' combined
with a suitable library search path specified via `-L', as it would be
usually the case, or just referring to the relevant .la file in a fully
libtool-enabled configuration such as ours.

According to an observation in the discussion back in 2007[1][2][3] that
has led to the current arrangement it is to prevent libtool from picking
up the wrong version of libbfd.  It does not appear to be needed though,
not at least with our current libtool incarnation, as directly referring
`libbfd.la' does exactly what it should, as previously suggested[4], and
with no link-time reference to the installation directory other than to
set RPATH.  Uninstalled version of libopcodes has libbfd's build-time
location prepended to RPATH too, as also expected.

Use a direct reference to `libbfd.la' then, making the load error quoted
above go away.  Alternatively `-L' and `-l' could be used to the same
effect, but it seems an unnecessary complication and just another way to
circumvent rather than making use of libtool.

References:

[1] "compile failure due to undefined symbol",
    <https://sourceware.org/ml/binutils/2007-08/msg00476.html>

[2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html>

[3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html>

[4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html>

opcodes/
* Makefile.am: Remove obsolete comment.
* configure.ac: Refer `libbfd.la' to link shared BFD library
except for Cygwin.
* Makefile.in: Regenerate.
* configure: Regenerate.

Automatic date update in version.in

gold: Place .note.gnu.property section before other note sections

Place the .note.gnu.property section before all other note sections to
avoid being placed between other note sections with different alignments.

PR gold/28494
* layout.cc (Layout::create_note): Set order to ORDER_PROPERTY_NOTE
for the .note.gnu.property section.
* layout.h (Output_section_order): Add ORDER_PROPERTY_NOTE.

[gdb/doc] Fix print inferior-events default

In the docs about print inferior-events we read:
...
By default, these messages will not be printed.
...

That used to be the case, but is no longer so since commit f67c0c91715 "Enable
'set print inferior-events' and improve detach/fork/kill/exit messages".

Fix this by updating the docs.

Automatic date update in version.in

gdb: change functions returning value contents to use gdb::array_view

The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content.  The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.

This made me think of changing functions that return value contents to
return array_views instead of a plain pointer.  This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.

This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice.  Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.

[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html

Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3

gdbsupport: add assertions in array_view

Add assertions to ensure we don't access an array_view out of bounds.
Enable these assertions only when _GLIBCXX_DEBUG is set, as we did for
gdb::optional.

Change-Id: Iffaee38252405073735ed123c8e57fde6b2c6be3

gdbserver: make target_pid_to_str return std::string

I wanted to write a warning that included two target_pid_to_str calls,
like this:

    warning (_("Blabla %s, blabla %s"),
     target_pid_to_str (ptid1),
     target_pid_to_str (ptid2));

This doesn't work, because target_pid_to_str stores its result in a
static buffer, so my message would show twice the same ptid.  Change
target_pid_to_str to return an std::string to avoid this.  I don't think
we save much by using a static buffer, but it is more error-prone.

Change-Id: Ie3f649627686b84930529cc5c7c691ccf5d36dc2

x86: Also handle stores for -muse-unaligned-vector-move

* config/tc-i386.c (encode_with_unaligned_vector_move): Also
handle stores.
* testsuite/gas/i386/unaligned-vector-move.s: Add stores.
* testsuite/gas/i386/unaligned-vector-move.d: Updated.
* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.

[gdb/testsuite] Fix duplicate in gdb.mi/mi-var-cp.exp

With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
...

This is due to a duplicate test name here:
...
$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
  ...
   100  int reference_to_struct ()
   101  {
   102    /*: BEGIN: reference_to_struct :*/
   103    S s = {7, 8};
   104    S& r = s;
   105    /*:
   106      mi_create_varobj S s "create varobj for s"
   107      mi_create_varobj R r "create varobj for s"
...

Fix this by using "create varobj for r" instead.

Tested on x86_64-linux.

libctf, ld: handle nonrepresentable types better

ctf_type_visit (used, among other things, by the type dumping code) was
aborting when it saw a nonrepresentable type anywhere: even a single
structure member with a nonrepresentable type caused an abort with
ECTF_NONREPRESENTABLE.  This is not useful behaviour, given that the
abort comes from a type-resolution we are only doing in order to
determine whether the type is a structure or union.  We know
nonrepresentable types can't be either, so handle that case and
pass the nonrepresentable type down.

(The added test verifies that the dumper now handles this case and
prints nonrepresentable structure members as it already does
nonrepresentable top-level types, rather than skipping the whole
structure -- or, without the previous commit, skipping the whole types
section.)

ld/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* testsuite/ld-ctf/nonrepresentable-member.*: New test.

libctf/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* ctf-types.c (ctf_type_rvisit): Handle nonrepresentable types.

libctf: dump: do not stop dumping types on error

If dumping of a single type fails, we obviously can't dump it; but just
as obviously this doesn't make the other types in the types section
invalid or undumpable.  So we should not propagate errors seen when
type-dumping, but rather ignore them and carry on, so we dump as many
types as we can (leaving out the ones we can't grok).

libctf/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* ctf-dump.c (ctf_dump_type): Do not abort on error.

binutils, ld: make objdump --ctf's parameter optional

ld by default (and always, unless adjusted with a hand-rolled linker
script) emits deduplicated CTF into the .ctf section.  But viewing
it needs you to explicitly tell objdump this: it doesn't default
its argument, even though what you always end up typing is
--ctf=.ctf.

This is annoying, so make the argument optional.

binutils/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* objdump.c (usage): --ctf now has an optional argument.
(main): Adjust accordingly.
(dump_ctf): Default it.
* doc/ctf.options.texi: Adjust.

ld/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* testsuite/ld-ctf/array.d: Change --ctf=.ctf to --ctf.
* testsuite/ld-ctf/conflicting-cycle-1.B-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.B-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-1.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.A-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-2.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-1.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.C-2.d: Likewise.
* testsuite/ld-ctf/conflicting-cycle-3.parent.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Likewise.
* testsuite/ld-ctf/conflicting-typedefs.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-cyclic-nonconflicting.d: Likewise.
* testsuite/ld-ctf/cross-tu-into-cycle.d: Likewise.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/cycle-1.d: Likewise.
* testsuite/ld-ctf/cycle-2.A.d: Likewise.
* testsuite/ld-ctf/cycle-2.B.d: Likewise.
* testsuite/ld-ctf/cycle-2.C.d: Likewise.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/diag-cttname-null.d: Likewise.
* testsuite/ld-ctf/diag-cuname.d: Likewise.
* testsuite/ld-ctf/diag-parlabel.d: Likewise.
* testsuite/ld-ctf/enum-forward.d: Likewise.
* testsuite/ld-ctf/enums.d: Likewise.
* testsuite/ld-ctf/forward.d: Likewise.
* testsuite/ld-ctf/function.d: Likewise.
* testsuite/ld-ctf/nonrepresentable.d: Likewise.
* testsuite/ld-ctf/slice.d: Likewise.
* testsuite/ld-ctf/super-sub-cycles.d: Likewise.

binutils: make objdump/readelf --ctf-parent actually useful

This option has been present since the very early days of the
development of libctf as part of binutils, and it shows.  Back in the
earliest days, I thought we might handle ambiguous types by introducing
new ELF sections on the fly named things like .ctf.foo.c for ambiguous
types found only in foo.c, etc.  This turned out to be a terrible idea,
so we moved to using a CTF archive in the .ctf section which contained
all the CTF dictionaries -- but the --ctf-parent option in objdump and
readelf was never adjusted, and lingered as a mechanism to specify CTF
parent dictionaries in sections other than .ctf, even though the linker
has no way to produce parent dictionaries in different sections from
their children, libctf's ctf_open can't handle such split-up
parent/child dicts, and they are never found in the wild, emitted by GNU
ld or by any known third-party linking tool.

Meanwhile, the actually-useful ctf_link feature (albeit not used by ld)
which lets you remap the names of CTF archive members (so you can end up
with a parent archive member named something other than ".ctf", still
contained with all its children in a single .ctf section) had no support
in objdump or readelf: there was no way to tell them that these members
were parents, so all the types in the associated child dicts always
appeared corrupted, referencing nonexistent types from a parent objdump
couldn't find.

So adjust --ctf-parent so that rather than taking a section name it
takes a member name instead (if not specified, the name is ".ctf", which
is what GNU ld emits).  Because the option was always useless before
now, this is expected to have no backward-compatibility implications.

As part of this, we have to slightly adjust the code which skips the
archive member name if redundant: right now it skips it if it's ".ctf",
on the assumption that this name will almost always be at the start
of the objdump output and thus we'll end up with a shared dump
and then smaller, headed dumps for the per-TU child dicts; but if
the parent name has been changed, that won't be true any more.

So change the rules to "members named .ctf which appear first in the
first have their member name skipped".  Since we now need to count
members, move from ctf_archive_iter (for which passing in extra
parameters requires defining a new struct and is clumsy) to
ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and
maintain a member count in the obvious way.  In the process we fix a
tiny difference between readelf and objdump: if a ctf_dump ever failed,
readelf skipped every later member, while objdump tried to keep going as
much as it could.  For a dumping tool the former is clearly preferable.

binutils/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* objdump.c (usage): --ctf-parent now takes a name, not a section.
(dump_ctf): Don't open a separate section; use the parent_name in
ctf_dict_open instead.  Use ctf_archive_next, not ctf_archive_iter,
so we can pass down a member count.
(dump_ctf_archive_member): Add the member count; don't return
anything.  Import parents into children no matter what the
parent's name, while still avoiding displaying the header for the
common parent name of ".ctf".
* readelf.c (usage): Adjust similarly.
(dump_section_as_ctf): Likewise.
(dump_ctf_archive_member): Likewise.  Never stop iterating over
archive members, even if ctf_dump of one member fails.
* doc/ctf.options.texi: Adjust.

objdump doesn't accept -L option

A followup to commit ca0e11aa4b.

* objdump.c (main): Add 'L' to short options and sort them.

bfd_nonfatal_message, localise va_start

Nothing to see here, just a little tidier.

* bucomm.c (bfd_nonfatal_message): Localise va_list args.

ubsan: _bfd_xcoff64_swap_aux_in left shift of negative value

* coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Use bfd_vma for h.

asan: evax_bfd_print_image buffer overflow

* vms-alpha.c (evax_bfd_print_image): Sanity check printing of
"image activator fixup" section.
(evax_bfd_print_relocation_records): Sanity check buffer offsets.
(evax_bfd_print_address_fixups): Likewise.
(evax_bfd_print_reference_fixups): Likewise.

Automatic date update in version.in

asan: c4x, c54x coff_canonicalize_reloc buffer overflow

Sometimes the investigation of a fuzzing bug report leads into areas
you'd rather not go.  In this instance by the time I'd figured out the
real cause was a target variant that had never been properly supported
in binutils, the time needed to fix it was less than the time needed
to rip it out.

* coffcode.h (coff_set_alignment_hook): Call bfd_coff_swap_reloc_in
not coff_swap_reloc_in.
(coff_slurp_reloc_table): Likewise.  Don't use RELOC type.
(ticoff0_swap_table): Use coff_swap_reloc_v0_out and
coff_swap_reloc_v0_in.
* coffswap.h (coff_swap_reloc_v0_in, coff_swap_reloc_v0_out): New.
* coff-tic54x.c (tic54x_lookup_howto): Don't abort.
* coffgen.c (coff_get_normalized_symtab): Use PTR_ADD.
* bfd-in.h (PTR_ADD, NPTR_ADD): Avoid warnings when passing an
expression.
* bfd-in2.h: Regenerate.

asan: arm-darwin: buffer overflow

PR 21813
* mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Sanity
check PAIR reloc in other branch of condition as was done for
PR21813.  Formatting.  Delete debug printf.

asan: aout: heap buffer overflow

* aoutx.h (aout_get_external_symbols): Sanity check before writing
zero index entry.  Remove outdated comment.
* pdp11.c (aout_get_external_symbols): Likewise.

LoongArch ld support

2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
    Zhensong Liu  <liuzhensong@loongson.cn>
    Weinan Liu  <liuweinan@loongson.cn>
    Xiaolin Tang  <tangxiaolin@loongson.cn>

ld/
* Makefile.am: Add LoongArch.
* NEWS: Mention LoongArch support.
* configure.tgt: Add LoongArch.
* emulparams/elf32loongarch-defs.sh: New.
* emulparams/elf32loongarch.sh: Likewise.
* emulparams/elf64loongarch-defs.sh: Likewise.
* emulparams/elf64loongarch.sh: Likewise.
* emultempl/loongarchelf.em: Likewise.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
ld/testsuite/
* ld-loongarch-elf/disas-jirl.d: New.
* ld-loongarch-elf/disas-jirl.s: Likewise.
* ld-loongarch-elf/jmp_op.d: Likewise.
* ld-loongarch-elf/jmp_op.s: Likewise.
* ld-loongarch-elf/ld-loongarch-elf.exp: Likewise.
* ld-loongarch-elf/macro_op.d: Likewise.
* ld-loongarch-elf/macro_op.s: Likewise.
* ld-loongarch-elf/syscall-0.s: Likewise.
* ld-loongarch-elf/syscall-1.s: Likewise.
* ld-loongarch-elf/syscall.d: Likewise.
* ld-srec/srec.exp: Add LoongArch.
* ld-unique/pr21529.d: Likewise.

LoongArch gas support

2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
            Zhensong Liu  <liuzhensong@loongson.cn>
            Weinan Liu  <liuweinan@loongson.cn>
    Xiaolin Tang  <tangxiaolin@loongson.cn>

gas/
* Makefile.am: Add LoongArch.
* NEWS: Mention LoongArch support.
* config/loongarch-lex-wrapper.c: New.
* config/loongarch-lex.h: New.
* config/loongarch-lex.l: New.
* config/loongarch-parse.y: New.
* config/tc-loongarch.c: New.
* config/tc-loongarch.h: New.
* configure.ac: Add LoongArch.
* configure.tgt: Likewise.
* doc/as.texi: Likewise.
* doc/c-loongarch.texi: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
gas/testsuite/
* gas/all/gas.exp: Add LoongArch.
* gas/elf/elf.exp: Likewise.
* gas/loongarch/4opt_op.d: New.
* gas/loongarch/4opt_op.s: Likewise.
* gas/loongarch/fix_op.d: Likewise.
* gas/loongarch/fix_op.s: Likewise.
* gas/loongarch/float_op.d: Likewise.
* gas/loongarch/float_op.s: Likewise.
* gas/loongarch/imm_op.d: Likewise.
* gas/loongarch/imm_op.s: Likewise.
* gas/loongarch/jmp_op.d: Likewise.
* gas/loongarch/jmp_op.s: Likewise.
* gas/loongarch/load_store_op.d: Likewise.
* gas/loongarch/load_store_op.s: Likewise.
* gas/loongarch/loongarch.exp: Likewise.
* gas/loongarch/macro_op.d: Likewise.
* gas/loongarch/macro_op.s: Likewise.
* gas/loongarch/nop.d: Likewise.
* gas/loongarch/nop.s: Likewise.
* gas/loongarch/privilege_op.d: Likewise.
* gas/loongarch/privilege_op.s: Likewise.
* gas/loongarch/syscall.d: Likewise.
* gas/loongarch/syscall.s: Likewise.
* lib/gas-defs.exp: Add LoongArch.

LoongArch binutils support

2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
    Zhensong Liu  <liuzhensong@loongson.cn>
    Weinan Liu  <liuweinan@loongson.cn>
binutils/
* NEWS: Mention LoongArch support.
* readelf.c: Add LoongArch.
* testsuite/binutils-all/objdump.exp: Add LoongArch.

LoongArch opcodes support

2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
    Zhensong Liu  <liuzhensong@loongson.cn>
    Weinan Liu  <liuweinan@loongson.cn>

include/
* opcode/loongarch.h: New.
* dis-asm.h: Declare print_loongarch_disassembler_options.
opcodes/
* Makefile.am: Add LoongArch.
* configure.ac: Likewise.
* disassemble.c: Likewise.
* disassemble.h: Declare print_insn_loongarch.
* loongarch-coder.c: New.
* loongarch-dis.c: New.
* loongarch-opc.c: New.
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.

LoongArch bfd support

2021-10-22  Chenghua Xu  <xuchenghua@loongson.cn>
    Zhensong Liu  <liuzhensong@loongson.cn>
    Weinan Liu  <liuweinan@loongson.cn>
bfd/
* Makefile.am: Add LoongArch.
* archures.c: Likewise.
* config.bfd: Likewise.
* configure.ac: Likewise.
* cpu-loongarch.c: New.
* elf-bfd.h: Add LoongArch.
* elf.c: Add LoongArch elfcore_grok_xxx.
* elfnn-loongarch.c: New.
* elfxx-loongarch.c: New.
* elfxx-loongarch.h: New.
* reloc.c: Add LoongArch BFD RELOC ENUM.
* targets.c: Add LoongArch target.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* configure: Regenerate.
* libbfd.h: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

include/
* elf/common.h: Add NT_LARCH_{CPUCFG,CSR,LSX,LASX}.
* elf/loongarch.h: New.

Automatic date update in version.in

Automatic date update in version.in

x86: Add -muse-unaligned-vector-move to assembler

Unaligned load/store instructions on aligned memory or register are as
fast as aligned load/store instructions on modern Intel processors.  Add
a command-line option, -muse-unaligned-vector-move, to x86 assembler to
encode encode aligned vector load/store instructions as unaligned
vector load/store instructions.

* NEWS: Mention -muse-unaligned-vector-move.
* config/tc-i386.c (use_unaligned_vector_move): New.
(encode_with_unaligned_vector_move): Likewise.
(md_assemble): Call encode_with_unaligned_vector_move for
-muse-unaligned-vector-move.
(OPTION_MUSE_UNALIGNED_VECTOR_MOVE): New.
(md_longopts): Add -muse-unaligned-vector-move.
(md_parse_option): Handle -muse-unaligned-vector-move.
(md_show_usage): Add -muse-unaligned-vector-move.
* doc/c-i386.texi: Document -muse-unaligned-vector-move.
* testsuite/gas/i386/i386.exp: Run unaligned-vector-move and
x86-64-unaligned-vector-move.
* testsuite/gas/i386/unaligned-vector-move.d: New file.
* testsuite/gas/i386/unaligned-vector-move.s: Likewise.
* testsuite/gas/i386/x86-64-unaligned-vector-move.d: Likewise.

Fix 'uninstall' target

This adds some missing code to the 'uninstall' targets in gdb and
gdbserver.  It also changes gdb's uninstall target so that it no
longer tries to remove any man page -- this is already done (and more
correctly) by doc/Makefile.in.

I tested this with 'make install' followed by 'make uninstall', then
examining the install tree for regular files.  Only the 'dir' file
remains, but this appears to just be how 'install-info' is intended to
work.

Remove unused variables from gdbserver's Makefile

This removes a number of unused variables from gdbserver's Makefile.
I found these while working on the subsequent patches, and figured it
would be cleaner to have a separate patch for the deletions.

[gdb/testsuite] Fix gdb.threads/linux-dp.exp

On openSUSE Tumbleweed with glibc-debuginfo installed I get:
...
 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
 where^M
 #0  print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
 #1  0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
 #2  0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
                          at pthread_create.c:435^M
 #3  0x00007ffff7ddb640 in clone3 () \
                          at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
 (gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
while without debuginfo installed I get instead:
...
 (gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
 where^M
 #0  print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
 #1  0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
 #2  0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
 #3  0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
 (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...

The problem is that the regexp used:
...
  "\(from .*libpthread\|at pthread_create\|in pthread_create\)"
...
expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
been merged into libc.

Fix this by updating the regexp.

Tested on x86_64-linux.

[gdb/testsuite] Fix FAILs in gdb.mi/mi-breakpoint-changed.exp

Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
Expecting: ^(-break-insert -f pendfunc1[^M
]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
  bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-insert -f pendfunc1^M
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
  addr="0x00007ffff7bd559e",func="pendfunc1",\
  file="gdb/testsuite/gdb.mi/pendshr1.c",\
  fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
  times="0",original-location="pendfunc1"}^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
  -break-insert -f pendfunc1 (unexpected output)
...

The regexp expects a breakpoint-created event, but that's actually suppressed
by the command:
...
DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
                   &mi_suppress_notification.breakpoint),
...

Fix this by updating the regexp.

Likewise for the following:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
  -break-insert -f pendfunc1
Expecting: ^(-break-enable count 1 2[^M
]+)?(=breakpoint-modified,\
  bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-enable count 1 2^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
  -break-enable count 1 2 (unexpected out\
put)
...

Tested on x86_64-linux.

gdb/python: move gdb.Membuf support into a new file

In a future commit I'm going to be creating gdb.Membuf objects from a
new file within gdb/python/py*.c.  Currently all gdb.Membuf objects
are created directly within infpy_read_memory (as a result of calling
gdb.Inferior.read_memory()).

Initially I split out the Membuf creation code into a new function,
and left the new function in gdb/python/py-inferior.c, however, it
felt a little random that the Membuf creation code should live with
the inferior handling code.

So, then I moved all of the Membuf related code out into a new file,
gdb/python/py-membuf.c, the interface is gdbpy_buffer_to_membuf, which
wraps an array of bytes into a gdb.Membuf object.

Most of the code is moved directly from py-inferior.c with only minor
tweaks to layout and replacing NULL with nullptr, hence, I've left the
copyright date on py-membuf.c as 2009-2021 to match py-inferior.c.

Currently, the only user of this code is still py-inferior.c, but in
later commits this will change.

There should be no user visible changes after this commit.

gdb/python: new gdb.architecture_names function

Add a new function to the Python API, gdb.architecture_names().  This
function returns a list containing all of the supported architecture
names within the current build of GDB.

The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().

gdb: make disassembler fprintf callback a static member function

The disassemble_info structure has four callbacks, we have three of
them as static member functions within gdb_disassembler, the fourth is
just a global static function.

However, this fourth callback, is still only used from the
disassemble_info struct, so there's no real reason for its special
handling.

This commit makes fprintf_disasm a static method within
gdb_disassembler.

There should be no user visible changes after this commit.

RISC-V: Added ld testcase for pcgp relaxation.

Consider the the pcgp-relax-02 testcase,

        .text
        .globl _start
_start:
.L1:    auipc   a0, %pcrel_hi(data_a)
.L2:    auipc   a1, %pcrel_hi(data_b)
        addi    a0, a0, %pcrel_lo(.L1)
        addi    a1, a1, %pcrel_lo(.L2)

        .data
        .word 0x0
        .globl data_a
data_a:
        .word 0x1

        .section .rodata
        .globl data_b
data_b:
        .word 0x2

If the first auipc is deleted, but we are still building the pcgp
table (connect the high and low pcrel relocations), then there is
an aliasing issue that we need some way to disambiguate which of
the two symbols we are targeting.  Therefore, Palmer thought of a
way to use R_RISCV_DELETE to split this into two phases, so we
could resolve the addresses before creating the ambiguities.

This patch just add the ld testcase for the above case, in case we
have changed something but break this.

ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Renamed pcgp-relax
to pcgp-relax-01, and added pcgp-relax-02.
* testsuite/ld-riscv-elf/pcgp-relax-01.d: Renmaed from pcgp-relax.
* testsuite/ld-riscv-elf/pcgp-relax-01.s: Likewise.
* testsuite/ld-riscv-elf/pcgp-relax-02.d: New testcase.
* testsuite/ld-riscv-elf/pcgp-relax-02.s: Likewise.

RISC-V: Don't separate pcgp relaxation to another relax pass.

Commit abd20cb637008da9d32018b4b03973e119388a0a and
ebdcad3fddf6ec21f6d4dcc702379a12718cf0c4 introduced additional
complexity into the paths run by the RISC-V relaxation pass in order to
resolve the issue of accurately keeping track of pcrel_hi and pcrel_lo
pairs. The first commit split up relaxation of these relocs into a pass
which occurred after other relaxations in order to prevent the situation
where bytes were deleted in between a pcrel_lo/pcrel_hi pair, inhibiting
our ability to find the corresponding pcrel_hi relocation from the
address attached to the pcrel_lo.

Since the relaxation was split into two passes the 'again' parameter
could not be used to perform the entire relaxation process again and so
the second commit added a way to restart ldelf_map_segments, thus
starting the whole process again.

Unfortunately this process could not account for the fact that we were
not finished with the relaxation process so in some cases - such as the
case where code would not fit in a memory region before the
R_RISCV_ALIGN relocation was relaxed - sanity checks in generic code
would fail.

This patch fixes all three of these concerns by reverting back to a
system of having only one target relax pass but updating entries in the
table of pcrel_hi/pcrel_lo relocs every time any bytes are deleted. Thus
we can keep track of the pairs accurately, and we can use the 'again'
parameter to restart the entire target relax pass, behaving in the way
that generic code expects. Unfortunately we must still have an
additional pass to delay deleting AUIPC bytes to avoid ambiguity between
pcrel_hi relocs stored in the table after deletion. This pass can only
be run once so we may potentially miss out on relaxation opportunities
but this is likely to be rare.

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

bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Removed restart_relax.
(riscv_elf_link_hash_table_create): Updated.
(riscv_relax_delete_bytes): Moved after the riscv_update_pcgp_relocs.
Update the pcgp_relocs table whenever bytes are deleted.
(riscv_update_pcgp_relocs): Add function to update the section
offset of pcrel_hi and pcrel_lo, and also update the symbol value
of pcrel_hi.
(_bfd_riscv_relax_call): Need to update the pcgp_relocs table
when deleting codes.
(_bfd_riscv_relax_lui): Likewise.
(_bfd_riscv_relax_tls_le): Likewise.
(_bfd_riscv_relax_align): Once we've handled an R_RISCV_ALIGN,
we can't relax anything else, so set the sec->sec_flg0 to true.
Besides, we don't need to update the pcgp_relocs table at this
stage, so just pass NULL pointer as the pcgp_relocs table for
riscv_relax_delete_bytes.
(_bfd_riscv_relax_section): Use only one pass for all target
relaxations.
(_bfd_riscv_relax_delete): Likewise, we don't need to update
the pcgp_relocs table at this stage, and don't need to set
the `again' since restart_relax mechanism is abandoned.
(bfd_elfNN_riscv_restart_relax_sections): Removed.
(_bfd_riscv_relax_section): Updated.
* elfxx-riscv.h (bfd_elf32_riscv_restart_relax_sections): Removed.
(bfd_elf64_riscv_restart_relax_sections): Likewise.
ld/
* emultempl/riscvelf.em: Revert restart_relax changes and set
relax_pass to 3.
* testsuite/ld-riscv-elf/align-small-region.d: New testcase.
* testsuite/ld-riscv-elf/align-small-region.ld: Likewise.
* testsuite/ld-riscv-elf/align-small-region.s: Likewise.
* testsuite/ld-riscv-elf/restart-relax.d: Removed sine the
restart_relax mechanism is abandoned.
* testsuite/ld-riscv-elf/restart-relax.s: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.

gdb: fix remote-sim.c build

Commit 183be222907a ("gdb, gdbserver: make target_waitstatus safe")
broke the remote-sim.c build.  In fact, it does some wrong changes,
result of a bad sed invocation.

Fix it by adjusting the code to the new target_waitstatus API.

Change-Id: I3236ff7ef7681fc29215f68be210ff4263760e91

Automatic date update in version.in

gdb, gdbserver: make target_waitstatus safe

I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED.  This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid.  The read
signal value was therefore garbage, and that caused GDB to crash soon
after.  Or, since that GDB was built with ubsan, this nice error
message:

    /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'

Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug.  As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.

 - Make the kind and value of target_waitstatus private.
 - Make the kind initialized to TARGET_WAITKIND_IGNORE on
   target_waitstatus construction.  This is what most users appear to do
   explicitly.
 - Add setters, one for each kind.  Each setter takes as a parameter the
   data associated to that kind, if any.  This makes it impossible to
   forget to attach the associated data.
 - Add getters, one for each associated data type.  Each getter
   validates that the data type fetched by the user matches the wait
   status kind.
 - Change "integer" to "exit_status", "related_pid" to "child_ptid",
   just because that's more precise terminology.
 - Fix all users.

That last point is semi-mechanical.  There are a lot of obvious changes,
but some less obvious ones.  For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.

This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards).  It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS.  The rest of the changes to native
files was done as a best effort.  If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).

Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7

gdbserver: initialize the members of lwp_info in-class

Add a constructor to initialize the waitstatus members.  Initialize the
others in the class directly.

Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442

gdbserver: make thread_info non-POD

Add a constructor and a destructor.  The constructor takes care of the
initialization that happened in add_thread, while the destructor takes
care of the freeing that happened in free_one_thread.  This is needed to
make target_waitstatus non-POD, as thread_info contains a member of that
type.

Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7

Fix ARMv8.4 for hw watchpoint and breakpoint

Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
this adds ARMv8.4 debug arch as being compatible for hw watchpoint
and breakpoints.

Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity)

Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.

Fixes for gdb.mi/mi-break.exp

Update the expected pattern for two of the tests.

Matching pattern \" doesn't work.  Use .*  to match the \* pattern.

[gdb/tui] Fix breakpoint display functionality

In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
-      for (bp = breakpoint_chain;
-           bp != NULL;
-           bp = bp->next)
+      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.

Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
-      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+      for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.

Consequently, breakpoints no longer show up in the tui source window.

Fix this by reverting the changes that introduced the two returns.

Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.

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

Fix test step-and-next-inline.cc

The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line.  To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.

On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.

Fix latent Ada bug when accessing field offsets

The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite.  This turned
out to be a latent bug in ada-lang.c.

The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS.  This causes an assert for a
dynamic type.

This patch fixes the problem by doing two things.  First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller.  This
works because the offset isn't used in any other way -- only as a
result.

Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed.  For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly.  In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).

Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.

I've updated an existing test case to reproduce the crash.
I'm checking this in.

-Waddress warning in ldelf.c

ldelf.c: In function 'ldelf_after_open':
ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
 1049 |           && elf_tdata (abfd)->elf_header != NULL
      |                                           ^~
In file included from ldelf.c:37:
../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
 1957 |   Elf_Internal_Ehdr elf_header[1];      /* Actual data, but ref like ptr */

* ldelf.c (ldelf_after_open): Remove useless elf_header test.

Avoid -Waddress warnings in readelf

Mainline gcc:
readelf.c: In function 'find_section':
readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
  349 |   ((X) != NULL                                                          \
      |        ^~
readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
  761 |     if (SECTION_NAME_VALID (filedata->section_headers + i)
      |         ^~~~~~~~~~~~~~~~~~

This will likely be fixed in gcc, but inline functions are nicer than
macros.

* readelf.c (SECTION_NAME, SECTION_NAME_VALID),
(SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
(GET_DYNAMIC_NAME): Delete.  Replace with..
(section_name, section_name_valid, section_name_print),
(valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
new inline functions.  Update use throughout file.

Automatic date update in version.in

PR28417, std::string no longer allows accepting nullptr_t

PR 28417
* incremental.cc (Sized_relobj_incr::do_section_name): Avoid
std:string undefined behaviour.
* options.h (Search_directory::Search_directory): Likewise.

Re: PR27625, powerpc64 gold __tls_get_addr calls

My previous PR27625 patch had a problem or two.  For one, the error
"__tls_get_addr call lacks marker reloc" on processing some calls
before hitting a call without markers typically isn't seen.  Instead a
gold assertion fails.  Either way it would be a hard error, which
triggers on a file contained in libphobos.a when running the gcc
testsuite.  A warning isn't even appropriate since the call involved
is one built by hand without any of the arg setup relocations that
might result in linker optimisation.

So this patch reverts most of commit 0af4fcc25dd5, instead entirely
ignoring the problem of mis-optimising old-style __tls_get_addr calls
without marker relocs.  We can't handle them gracefully without
another pass over relocations before decisions are made about GOT
entries in Scan::global or Scan::local.  That seems too costly, just
to link object files from 2009.  What's more, there doesn't seem to be
any way to allow the libphobos explicit __tls_get_addr call, but not
old TLS sequences without marker relocs.  Examining instructions
before the __tls_get_addr call is out of the question: program flow
might reach the call via a branch.  Putting an R_PPC64_TLSGD marker
with zero sym on the call might be a solution, but current linkers
will then merrily optimise away the call!

PR gold/27625
* powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors.  Remove all uses.

Use std::string in print_one_catch_syscall

This changes print_one_catch_syscall to use std::string, removing a
bit of manual memory management.

Use unique_xmalloc_ptr in breakpoint

This changes struct breakpoint to use unique_xmalloc_ptr in a couple
of spots, removing a bit of manual memory management.

Use unique_xmalloc_ptr in bp_location

This changes struct bp_location to use a unique_xmalloc_ptr, removing
a bit of manual memory management.

Use unique_xmalloc_ptr in watchpoint

This changes struct watchpoint to use unique_xmalloc_ptr in a couple
of places, removing a bit of manual memory management.

Use unique_xmalloc_ptr in exec_catchpoint

This changes struct exec_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.

Use unique_xmalloc_ptr in solib_catchpoint

This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.

Make c-exp.y work with Bison 3.8+

When using Bison 3.8, we get this error:

    ../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]

That's because bison 3.8 removed YYPRINT support:
https://savannah.gnu.org/forum/forum.php?forum_id=10047

Accordingly, this patch only defines that function for Bison < 3.8.

Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad

Automatic date update in version.in

[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest

The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result

The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.

Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal

Tested on x86_64-linux.

Check index in type::field

This changes gdb to check the index that is passed to type::field.
This caught one bug in the Ada code when running the test suite
(actually I found the bug first, then realized that the check would
have helped), so this patch fixes that as well.

Regression tested on x86-64 Fedora 34.

Fix Rust lex selftest when using libiconv

The Rust lex selftest fails on our Windows build.  I tracked this down
to a use of UTF-32 as a parameter to convert_between_encodings.  Here,
iconv_open succeeds, but the actual conversion of a tab character
fails with EILSEQ.  I suspect that "UTF-32" is being interpreted as
big-endian, as changing the call to use "UTF-32LE" makes it work.
This patch implements this fix.

Fix format_pieces selftest on Windows

The format_pieces selftest currently fails on Windows hosts.

The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
formatter may perform, but also gdbsupport was missing a configure
check for PRINTF_HAS_LONG_LONG.  This patch fixes both issues.

Fix bug in dynamic type resolution

A customer-reported problem led us to a bug in dynamic type
resolution.  resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved.  While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.

This patch fixes the bug, by offsetting both.  A test case is included
that can be used to reproduce the bug.

Always use std::function for self-tests

Now that there is a register_test variant that accepts std::function,
it seems to me that the 'selftest' struct and accompanying code is
obsolete -- simply always using std::function is simpler.  This patch
implements this idea.

Fix PR gdb/17917 Lookup build-id in remote binaries

GDB doesn't support loading debug files using build-id from remote
target filesystems.

This is the case when gdbserver attached to a process and a gdb target
remote occurs over tcp.

With this change we make build-id lookups possible:

    (gdb) show debug-file-directory
    The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
    (gdb) set debug-file-directory /usr/lib/debug
    (gdb) show sysroot
    The current system root is "target:".
    (gdb) target extended-remote :46615
    Remote debugging using :46615
    warning: Can not parse XML target description; XML support was disabled at compile time
    Reading /usr/sbin/mariadbd from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /usr/sbin/mariadbd from remote target...
    Reading symbols from target:/usr/sbin/mariadbd...
    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug...
    Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
    ...

Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):

    (gdb) target extended-remote :46615
    Remote debugging using :46615
    Reading /usr/sbin/mariadbd from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /usr/sbin/mariadbd from remote target...
    Reading symbols from target:/usr/sbin/mariadbd...
    Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Missing separate debuginfo for target:/usr/sbin/mariadbd
    Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
    (No debugging symbols found in target:/usr/sbin/mariadbd)

Observe it didn't look for
/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
on the remote target (where it is) and expected them to be installed
locally.

As a minor optimization, this also changes the build-id lookup such that
if sysroot is empty, no second lookup of the same location is performed.

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

Fix a potential illegal memory access when testing for a special LTO symbol name.

bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
name before checking to see if the symbol is __gnu_lto_slim.
* archive.c (_bfd_compute_and_write_armap): Likewise.
binutils
* nm.c (filter_symbols): Test for a NULL name before checking to
see if the symbol is __gnu_lto_slim.
* objcopy.c (filter_symbols): Likewise.

Automatic date update in version.in

CTF: incorrect underlying type setting for enumeration types

A bug was filed against the incorrect underlying type setting for
an enumeration type, which was caused by a copy and paste error.
This patch fixes the problem by setting it by calling objfile_int_type,
which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
Also add error checking on ctf_func_type_info call.

Automatic date update in version.in

PR28459, readelf issues bogus warning

I'd missed the fact that the .debug_rnglists dump doesn't exactly
display the contents of the section.  Instead readelf rummages through
.debug_info looking for DW_AT_ranges entries, then displays the
entries in .debug_rnglists pointed at, sorted.  A simpler dump of the
actual section contents might be more useful and robust, but it was
likely done that way to detect overlap and holes.

Anyway, the headers in .debug_rnglists besides the first are ignored,
and limiting to the unit length of the first header fails if there is
more than one unit.

PR 28459
* dwarf.c (display_debug_ranges): Don't constrain data to length
in header.

Automatic date update in version.in

ld: Adjust pr28158.rd for glibc 2.34

Adjust pr28158.rd for glibc 2.34:

$ readelf -W --dyn-syms tmpdir/pr28158

Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (3)
$

vs older glibc:

$ readelf -W --dyn-syms tmpdir/pr28158

Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (3)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (2)

$

* testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.

Automatic date update in version.in

Automatic date update in version.in

Powerpc: Add support for openat and fstatat syscalls

[gdb] update ppc-linux-tdep.c

Add argument to ppc_canonicalize_syscall for the wordsize.
Add syscall entries for the openat and fstatat system calls.

[gdb/testsuite] Add .debug_loc support in dwarf assembler

Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).

Tested on x86_64-linux.

[GOLD] Re: PowerPC64: Don't pretend to support multi-toc

We can't get at section->address() until everything is laid out, so
trying to generalise the offset calculation rather than using a value
of 0x8000 (the old object->toc_base_offset()) was bound to fail.
got->g_o_t() is a little better than a hard-coded 0x8000.

* powerpc.cc (Target_powerpc::Scan::local, global): Don't use
toc_pointer() here.

[GOLD] Two GOT sections for PowerPC64

Split .got into two piece, one with the header and entries for small
model got entries, the other with entries for medium/large model got
entries.  The idea is to better support mixed pcrel/non-pcrel code
where non-pcrel small-model .toc entries need to be within 32k of the
toc pointer.

* target.h (Target::tls_offset_for_local): Add got param.
(Target::tls_offset_for_global): Likewise.
(Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
* output.h (Output_data_got::Got_entry::write): Add got param.
* output.cc (Output_data_got::Got_entry::write): Likewise, pass to
tls_offset_for_local/global calls.
(Output_data_got::do_write): Adjust to suit.
* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
(Target_s390::do_tls_offset_for_global): Likewise.
* powerpc.cc (enum Got_type): Extend with small types, move from
class Target_powerpc.
(Target_powerpc::biggot_): New.
(Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
got_size, got_section, got_base_offset): Handle biggot_.
(Target_powerpc::do_define_standard_symbols): Adjust.
(Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
(Output_data_got_powerpc::Output_data_got_powerpc): Only make
64-bit header for small got section.
(Output_data_got_powerpc::g_o_t): Only return a result for small
got section.
(Output_data_got_powerpc::write): Only write small got section
header.
(Target_powerpc::Scan::local, global): Select small/big Got_type
and section to suit reloc.
(Target_powerpc::Relocate::relocate): Similarly.
(Sort_toc_sections): Rewrite.

[GOLD] PowerPC64: Don't pretend to support multi-toc

Code in powerpc.cc is pretending to support a per-object toc pointer
value, but powerpc gold has no real support for multi-toc.  This patch
removes the pretense, tidying quite a lot in preparation for a
followup patch.  If multi-toc is ever to be supported, don't revert
this patch but start by adding object parameter to toc_pointer() and
an object to Branch_stub_key.

* powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
(Target_powerpc::toc_pointer): New function.  Use throughout.
(Target_powerpc::got_base_offset): New function.  Use throughout..
(Output_data_got_powerpc::got_base_offset): ..in place of
this.  Delete.
(Output_data_got_powerpc::Output_data_got_powerpc): Init
header_index_ to -1u for 64-bit, and make header here.
(Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
make 64-bit header here.
(Output_data_got_powerpc::g_o_t): Return toc pointer offset in
section for 64-bit.  Use throughout.
(Stub_table): Remove toc_base_off_ from Branch_stub_key, and
object param on add_long_branch_entry and find_long_branch_entry.
Adjust all uses.

Re: s12z/disassembler: call memory_error_func when appropriate

Adjust for commit ba7c18a48457.

* testsuite/gas/s12z/truncated.d: Update expected output.

Automatic date update in version.in

[gdb/exp] Improve <error reading variable> message

When printing a variable x in a subroutine foo:
...
subroutine foo (x)
  integer(4) :: x (*)
  x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
  -ex "break foo" \
  -ex run \
  -ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.

Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18        x(3) = 1
$1 = <error reading variable>
...

Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...

This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.

Tested on x86_64-linux.

PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)

[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.

The GDB record function was recording the variable addr that was passed in
rather than the calculated effective address (ea) by the
ppc_process_record_op31 function.

gdb: improve error reporting from the disassembler

If the libopcodes disassembler returns a negative value then this
indicates that the disassembly failed for some reason.  In disas.c, in
the function gdb_disassembler::print_insn we can see how this is
handled; when we get a negative value back, we call the memory_error
function, which throws an exception.

The problem here is that the address used in the memory_error call is
gdb_disassembler::m_err_memaddr, which is set in
gdb_disassembler::dis_asm_memory_error, which is called from within
the libopcodes disassembler through the
disassembler_info::memory_error_func callback.

However, for this to work correctly, every time the libopcodes
disassembler returns a negative value, the libopcodes disassembler
must have first called the memory_error_func callback.

My first plan was to make m_err_memaddr a gdb::optional, and assert
that it always had a value prior to calling memory_error, however, a
quick look in opcodes/*-dis.c shows that there _are_ cases where a
negative value is returned without first calling the memory_error_func
callback, for example in arc-dis.c and cris-dis.c.

Now, I think that a good argument can be made that these disassemblers
must therefore be broken, except for the case where we can't read
memory, we should always be able to disassemble the memory contents to
_something_, even if it's just '.word 0x....'.  However, I certainly
don't plan to go and fix all of the disassemblers.

What I do propose to do then, is make m_err_memaddr a gdb::optional,
but now, instead of always calling memory_error, I add a new path
which just calls error complaining about an unknown error.  This new
path is only used if m_err_memaddr doesn't have a value (indicating
that the memory_error_func callback was not called).

To test this I just augmented one of the disassemblers to always
return -1, before this patch I see this:

  Dump of assembler code for function main:
     0x000101aa <+0>: Cannot access memory at address 0x0

And after this commit I now see:

  Dump of assembler code for function main:
     0x000101aa <+0>: unknown disassembler error (error = -1)

This doesn't really help much, but that's because there's no way to
report non memory errors out of the disasembler, because, it was not
expected that the disassembler would ever report non memory errors.

[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver

When running test-case gdb.fortran/call-no-debug.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
call (integer) string_func_ (&'abcdefg', 3)^M
$2 = 0^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
...

The problem is that gdb_test is used to match inferior output.

Fix this by using gdb_test_stdio.

Tested on x86_64-linux.

[gdb/testsuite] Require use_gdb_stub == 0 where appropriate

When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.

Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.

Tested on x86_64-linux.