gas: Fix internal error in S_SET_SEGMENT

This patch fixes an internal error in GAS when defining a section using
a symbol that has already been named but not defined. For a minimal
reproducer, try the following input:

a=b
.sect a

The problem is that obj_elf_change_section() happily reuses the symbol
"a" created by equals() without clearing the sy_value field: prior to
this patch, it just set bsym. This caused a problem when attempting to
resolve the section symbol, since resolve_symbol_value() ended up
resolving the symbol as if it were the original symbol created by
equals(), which ends up leaving the section symbol in the undefined
section instead of in section a, hence the call to abort() in
S_SET_SEGMENT().

gas/ChangeLog:

* config/obj-elf.c (obj_elf_change_section): When repurposing an
existing symbol, ensure that we set sy_value as per other (fresh)
section symbols.
* testsuite/gas/elf/elf.exp: Add new test.
* testsuite/gas/elf/section-symbol-redef.d: New test.
* testsuite/gas/elf/section-symbol-redef.s: Input for test.

[gdb] Fix printing of unresolved dynamic type

When debugging gdb in batch mode with executable mixed-lang-stack and doing a
backtrace at breakpt:
...
$ gdb --args gdb \
  -batch \
  outputs/gdb.fortran/mixed-lang-stack/mixed-lang-stack \
  -ex "b breakpt" \
  -ex r \
  -ex bt
...
and stopping at resolve_dynamic_type to print the type:
...
(gdb) b resolve_dynamic_type
Breakpoint 1 at 0x6b020c: file gdbtypes.c, line 2633.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>call recursive_dump_type (type, 0)
>continue
>end
(gdb) run
...
we eventually run into an assert for the dynamic type of "str":
...
Thread 1 "gdb" hit Breakpoint 1, resolve_dynamic_type (type=0x22204f0, \
  valaddr=..., addr=4199408) at gdbtypes.c:2633
2633        = {check_typedef (type), valaddr, addr, NULL};
type node 0x22204f0
name '<NULL>' (0x0)
code 0xd (TYPE_CODE_STRING)
length 0
  ...
    nfields 0 0x22204b0
gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: \
  Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
when trying to print the high bound of a TYPE_CODE_RANGE, which has m_kind
PROP_LOCEXPR, while the code in resolve_dynamic_type assumes PROP_CONST.

Fix this by extending the printing of TYPE_CODE_RANGE to allow
PROP_LOCEXPR/PROP_LOCLIST as well, such that we have instead:
...
    nfields 0 0x1fbc020
    low 1  high (dynamic)
...

Tested on x86_64-linux.

gdb/ChangeLog:

2020-08-17  Tom de Vries  <tdevries@suse.de>

PR gdb/26393
* gdbtypes.c (dump_dynamic_prop): New function.
(recursive_dump_type): Use dump_dynamic_prop for TYPE_CODE_RANGE.

Automatic date update in version.in

PowerPC64 inline PLT call tests

* testsuite/ld-powerpc/inline.s,
* testsuite/ld-powerpc/inline-1.d,
* testsuite/ld-powerpc/inline-2.d,
* testsuite/ld-powerpc/inline-3.d,
* testsuite/ld-powerpc/inline-4.d,
* testsuite/ld-powerpc/inlinepcrel.s,
* testsuite/ld-powerpc/inlinepcrel-1.d,
* testsuite/ld-powerpc/inlinepcrel-2.d,
* testsuite/ld-powerpc/inlinepcrel-3.d: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.

ld: Add a PR binutils/26389 test

PR binutils/26389
* testsuite/ld-plugin/lto.exp: Run PR binutils/26389 test.
* testsuite/ld-plugin/pr26389.c: New file.
* testsuite/ld-plugin/pr26389.d: Likewise.

[gdb/testsuite] Add gdb.base/eh_return.exp

In PR25350, an internal error was reported:
...
(gdb) break *eh2+0x7e
Breakpoint 1 at 0x13e2: file small.c, line 38.
(gdb) run
Starting program: a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, 0x00005555555553e2 in eh2 (
frame.c:558: internal-error: frame_id get_frame_id(frame_info*): \
  Assertion `stashed' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...

The internal error does not reproduce after recent commit 547ce8f00b
"[gdb/backtrace] Fix printing of fortran string args".

Add the corresponding test-case as regression test, given that the code is
rather atypical.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-08-16  Tom de Vries  <tdevries@suse.de>

PR gdb/25350
* gdb.base/eh_return.c: New test.
* gdb.base/eh_return.exp: New file.

Automatic date update in version.in

[gdb/testsuite] Fix charlen type in mixed-lang-stack.c

In gdb.fortran/mixed-lang-stack.f90, we have fortran function mixed_func_1d:
...
subroutine mixed_func_1d(a, b, c, d, str)
  use, intrinsic :: iso_c_binding, only: c_int, c_float, c_double
  use, intrinsic :: iso_c_binding, only: c_float_complex
  implicit none
  integer(c_int) :: a
  real(c_float) :: b
  real(c_double) :: c
  complex(c_float_complex) :: d
  character(len=*) :: str
...
which we declare in C in gdb.fortran/mixed-lang-stack.c like this:
...
extern void mixed_func_1d_ (int *, float *, double *, complex float *,
                            char *, size_t);
...

The fortran string parameter str is passed as a char *, and an additional
argument str_ for the string length.  The type used for the string length
argument is size_t, but for gcc 7 and earlier, the actual type is int
instead ( see
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html ).

Fix this by declaring the string length type depending on the gcc version:
...
 #if !defined (__GNUC__) || __GNUC__ > 7
 typedef size_t fortran_charlen_t;
 #else
 typedef int fortran_charlen_t;
...

Tested on x86_64-linux, with gcc-7 and gcc-8.

gdb/testsuite/ChangeLog:

2020-08-15  Tom de Vries  <tdevries@suse.de>

* gdb.fortran/mixed-lang-stack.c (fortran_charlen_t): New type.
(mixed_func_1d_): Use fortran_charlen_t in decl.

[gdb/backtrace] Fix printing of fortran string args

When running test-case gdb.fortran/mixed-lang-stack.exp, it passes, but we
find in gdb.log:
...
 (gdb) bt^M
   ...
 #7  0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
   e=<error reading variable: value requires 140737488341744 bytes, which \
   is more than max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M
...
while a bit later in gdb.log, we have instead for the same frame (after
adding a gdb_test_no_output "set print frame-arguments all" to prevent
getting "e=..."):
...
 (gdb) up^M
 #7  0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
   e='abcdef', g=( a = 1.5, b = 2.5 ), _e=6) at mixed-lang-stack.f90:87^M
...

The difference is that in the latter case, we print the frame while it's
selected, while in the former, it's not.

The problem is that while trying to resolve the dynamic type of e in
resolve_dynamic_type, we call dwarf2_evaluate_property with a frame == NULL
argument, and then use the selected frame as the context in which to evaluate
the dwarf property, effectively evaluating a DW_OP_fbreg operation in the
wrong frame context.

Fix this by temporarily selecting the frame of which we're trying to print the
arguments in print_frame_args, borrowing code from print_frame_local_vars that
was added to fix a similar issue in commit 16c3b12f19 "error/internal-error
printing local variable during "bt full".

Build and tested on x86_64-linux.

gdb/ChangeLog:

2020-08-15  Tom de Vries  <tdevries@suse.de>

PR backtrace/26390
* stack.c (print_frame_args): Temporarily set the selected
frame to FRAME while printing the frame's arguments.

gdb/testsuite/ChangeLog:

2020-08-15  Tom de Vries  <tdevries@suse.de>

PR backtrace/26390
* gdb.fortran/mixed-lang-stack.exp: Call bt with -frame-arguments all.
Update expected pattern.

Set SEC_SMALL_DATA on small common

Unlike the previous patch setting SEC_SMALL_DATA during
elf_backend_symbol_processing, this patch is mostly cosmetic.

* elf32-frv.c (elf32_frv_add_symbol_hook): Set SEC_SMALL_DATA on
small common section.
* elf32-m32r.c (m32r_elf_add_symbol_hook): Likewise.
* elf32-microblaze.c (microblaze_elf_add_symbol_hook): Likewise.
* elf32-nds32.c (nds32_elf_add_symbol_hook): Likewise.
* elf32-nios2.c (nios2_elf_add_symbol_hook): Likewise.
* elf32-ppc.c (ppc_elf_add_symbol_hook): Likewise.
* elf32-score.c (s3_bfd_score_elf_add_symbol_hook): Likewise.
* elf32-score7.c (s7_bfd_score_elf_add_symbol_hook): Likewise.
* elf32-tic6x.c (elf32_tic6x_add_symbol_hook): Likewise.
* elf32-v850.c (v850_elf_check_relocs): Likewise.
(v850_elf_add_symbol_hook): Likewise.
* elf64-alpha.c (elf64_alpha_add_symbol_hook): Likewise.
* elf64-ia64-vms.c (elf64_ia64_add_symbol_hook): Likewise.
* elfnn-ia64.c (elfNN_ia64_add_symbol_hook): Likewise.
* elfxx-mips.c (_bfd_mips_elf_add_symbol_hook): Likewise.

PR26389, nm prints "c" for a common symbol with -flto and -fcommon

git commit 49d9fd42acef chose to make nm print 'C' for the normal
common section, and 'c' for other commons.  This was an attempt to
make common symbols in .scommon and other small common sections show
a 'c' type without a section name comparison, but it failed for
nm --plugin on lto objects where normal common symbols are stashed in
a "plug" section.  It's also wrong for large common symbols.  So
instead set SEC_SMALL_DATA on sections created for small commons, and
key off that flag to show 'c' type.  If your ELF target doesn't have
an elf_backend_symbol_processing function, then you won't see 'c' for
symbols in .scommon.

Note that due to bfd_decode_symclass decoding common symbols without
a chance for coff_section_type to treat .scommon specially, then
having .scommon in the array of special sections handled by
coff_section_type prior to 49d9fd42acef was entirely ineffective.
That fact escaped me when writing 49d9fd42acef.  Unless .scommon
didn't have SEC_IS_COMMON set, which would be a little weird.

PR 26389
* syms.c (bfd_decode_symclass): Choose 'c' for commons only when
SEC_SMALL_DATA.
* elf32-m32r.c (_bfd_m32r_elf_symbol_processing): Set SEC_SMALL_DATA
on small common section.
* elf32-score.c (s3_bfd_score_elf_symbol_processing): Likewise.
* elf32-score7.c (s7_bfd_score_elf_symbol_processing): Likewise.
* elf32-tic6x.c (elf32_tic6x_symbol_processing): Likewise.
* elf32-v850.c (v850_elf_symbol_processing): Likewise.
* elfxx-mips.c (_bfd_mips_elf_symbol_processing): Likewise.
* ecoff.c (ecoff_set_symbol_info, ecoff_link_add_externals): Likewise.

Automatic date update in version.in

[PowerPC] Always clear watchpoint with PTRACE_SET_DEBUGREG

This patches changes low_prepare_to_resume in the ppc linux native target
to always clear the watchpoint when the old PTRACE_SET_DEBUGREG interface
is used, even if another watchpoint GDB requested to the target is
written right after using the same call.

The reason for this is that there were some older kernel versions for
which overwriting a watchpoint with PTRACE_SET_DEBUGREG would not
re-activate the watchpoint if it was previouly disabled following a hit.
This happened when the kernel was configured with CONFIG_HW_BREAKPOINT on
and uses perf events to install watchpoints.

Previously, the ppc linux native target would immediately remove or
insert watchpoints following a request from the upper layers.  This was
changed in commit 227c0bf4b3dd0cf65dceb58e729e9da81b38b5a7 to fix other
issues, which caused watchpoint requests to be applied to the inferior
only in low_prepare_to_resume, right before the inferior is resumed.

Usually, but maybe not always, after a hit, GDB will remove the
watchpoint, resume the inferior for a single-step, possibly report the
watchpoint hit to the user, and then re-insert the watchpoint before the
inferior is next resumed.  In this case there would be no problems, but
since I can't guarantee that there aren't other paths in GDB that allow
the user to set a new watchpoint after the first one hit, and after its
deletion by GDB, but before the inferior is resumed, there is a chance
that PTRACE_SET_DEBUGREG could be called directly without the watchpoint
first having been cleared, which could cause a false negative with the
older kernel versions.

This issue would affect kernel versions starting from this commit:

5aae8a53708025d4e718f0d2e7c2f766779ddc71

Up to the fix in this commit:

a53fd61ac2f411745471c1c877d5e072fbbf0e5c

gdb/ChangeLog:

PR breakpoints/26385
* ppc-linux-nat.c (ppc_linux_nat_target::low_prepare_to_resume):
Always clear watchpoint with PTRACE_SET_DEBUGREG.

[PowerPC] Use < 0 and >= 0 for watchpoint ptrace calls

In commit 227c0bf4b3dd0cf65dceb58e729e9da81b38b5a7, which fixed some
watchpoint bugs, I compared the return value of some ptrace calls with ==
-1 and != -1.  Althought this should be correct, since the rest of the
file uses < 0 and >= 0, I have modified this for consistency.

gdb/ChangeLog:

* ppc-linux-nat.c (ppc_linux_dreg_interface::detect)
(ppc_linux_nat_target::low_prepare_to_resume): Use ptrace () < 0
and >= to check return value instead of == -1 and != -1.

gdb: add gdb_argv::as_array_view method

Introduce the gdb_argv::as_array_view method, as a way to easily pass
the parsed arguments array to a function taking an array view.  There is
currently one caller where we can use this (which prompted the
suggestion to implement this method).

Add some selftests for the new method, which at the same time test a
little bit gdb_argv.  As far as I know, it's not tested currently.

gdb/ChangeLog:

* utils.h (class gdb_argv) <as_array_view>: New method.
* utils.c (gdb_argv_as_array_view_test): New.
(_initialize_utils): Register selftest.
* maint.c (maintenance_selftest): Use the new method.

Change-Id: I0645037613ed6549aabe60f14a36f3494513b177

Allow larger bfd_default_hash_table_size

* hash.c (bfd_hash_set_default_size): Use higher_prime_number
rather than another copy of primes.  Increase maximum default
size allowed.

PR26388, objdump debug dump memory leaks

num_debug_info_entries is used not just as a count but also as a flag
(DEBUG_INFO_UNAVAILABLE) after some errors.  That means
num_debug_info_entries can't be used when cleaning up malloc'd info.

PR 26388
* dwarf.c (free_debug_memory): Free alloc_num_debug_info_entries
of debug_information.  Correct test of max_loc_offsets and
max_range_lists.
* rddbg.c (read_debugging_info): Free dhandle on error.

Readelf demangling test typo

Using floating point data results in cris failing the test.

* testsuite/binutils-all/mangled.s: Use dc.a rather than dc.d.

AArch64: Relax thumb-plt testcases regexpr.

The regexpr in these two files are a bit strict in that they don't account for
the slight changes in tags in certain arm targets which cause our address
offsets to change.   This changes the tests to allow slight movement in
locations while still strictly checking the rest.

ld/ChangeLog:

2020-08-03  Tamar Christina  <tamar.christina@arm.com>

* testsuite/ld-arm/thumb-plt-got.d: Relax regexpr.
* testsuite/ld-arm/thumb-plt.d: Likewise.

Automatic date update in version.in

gdb: Implement native dumpcore function for NetBSD

Define supports_dumpcore and dumpcore for NetBSD, that wraps
the ptrace(2) call with the PT_DUMPCORE operation.

gdb/ChangeLog:

       * nbsd-nat.h (nbsd_nat_target::supports_dumpcore)
       (nbsd_nat_target::dumpcore): New declarations.
       * nbsd-nat.c (nbsd_nat_target::supports_dumpcore)
       (nbsd_nat_target::dumpcore): New functions.

gdb: Implement native dumpcore function

Add new API for systems with native kernel support for dumping
a process on demand. Wire it into the gdb's gcore functionality.

gdb/ChangeLog:

       * target.h (supports_dumpcore, dumpcore): New
       function declarations.
       * target.c (supports_dumpcore, dumpcore): New
       functions.
       * target-delegates.c: Rebuild.
       * gcore.c (gcore_command): Use target_supports_dumpcore ()
       and target_dumpcore ().

debuginfod-support.c: Replace globals with user_data

Store query information in user_data struct instead of global variables.

gdb/ChangeLog:

* debuginfod-support.c: Replace global variables with user_data.

Add skip_fortran_tests to more Fortran testcases

This adds missing skip_fortran_tests checks to Fortran testcases,
using the exact same pattern the existing files that do check it use.

gdb/testsuite/ChangeLog:

* gdb.fortran/complex.exp: Check skip_fortran_tests.
* gdb.fortran/library-module.exp: Likewise.
* gdb.fortran/logical.exp: Likewise.
* gdb.fortran/module.exp: Likewise.
* gdb.fortran/print_type.exp: Likewise.
* gdb.fortran/vla-alloc-assoc.exp: Likewise.
* gdb.fortran/vla-datatypes.exp: Likewise.
* gdb.fortran/vla-history.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-ptype-sub.exp: Likewise.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-sizeof.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value-sub-arbitrary.exp: Likewise.
* gdb.fortran/vla-value-sub-finish.exp: Likewise.
* gdb.fortran/vla-value-sub.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.

Add skip_ada_tests to more Ada testcases

This adds missing skip_ada_tests checks to Ada testcases, using the
exact same pattern the existing files that do check it use.

gdb/testsuite/ChangeLog:

* gdb.ada/access_tagged_param.exp: Check skip_ada_tests.
* gdb.ada/access_to_packed_array.exp: Likewise.
* gdb.ada/access_to_unbounded_array.exp: Likewise.
* gdb.ada/addr_arith.exp: Likewise.
* gdb.ada/arr_acc_idx_w_gap.exp: Likewise.
* gdb.ada/arr_arr.exp: Likewise.
* gdb.ada/arr_enum_idx_w_gap.exp: Likewise.
* gdb.ada/array_bounds.exp: Likewise.
* gdb.ada/array_of_variable_length.exp: Likewise.
* gdb.ada/array_ptr_renaming.exp: Likewise.
* gdb.ada/array_subscript_addr.exp: Likewise.
* gdb.ada/arraydim.exp: Likewise.
* gdb.ada/arrayparam.exp: Likewise.
* gdb.ada/arrayptr.exp: Likewise.
* gdb.ada/assign_1.exp: Likewise.
* gdb.ada/assign_arr.exp: Likewise.
* gdb.ada/atomic_enum.exp: Likewise.
* gdb.ada/attr_ref_and_charlit.exp: Likewise.
* gdb.ada/bad-task-bp-keyword.exp: Likewise.
* gdb.ada/bias.exp: Likewise.
* gdb.ada/boolean_expr.exp: Likewise.
* gdb.ada/bp_c_mixed_case.exp: Likewise.
* gdb.ada/bp_enum_homonym.exp: Likewise.
* gdb.ada/bp_inlined_func.exp: Likewise.
* gdb.ada/bp_on_var.exp: Likewise.
* gdb.ada/bp_range_type.exp: Likewise.
* gdb.ada/bp_reset.exp: Likewise.
* gdb.ada/call_pn.exp: Likewise.
* gdb.ada/catch_assert_if.exp: Likewise.
* gdb.ada/catch_ex.exp: Likewise.
* gdb.ada/catch_ex_std.exp: Likewise.
* gdb.ada/char_enum.exp: Likewise.
* gdb.ada/char_param.exp: Likewise.
* gdb.ada/complete.exp: Likewise.
* gdb.ada/cond_lang.exp: Likewise.
* gdb.ada/convvar_comp.exp: Likewise.
* gdb.ada/dgopt.exp: Likewise.
* gdb.ada/disc_arr_bound.exp: Likewise.
* gdb.ada/display_nested.exp: Likewise.
* gdb.ada/dot_all.exp: Likewise.
* gdb.ada/dyn_loc.exp: Likewise.
* gdb.ada/dyn_stride.exp: Likewise.
* gdb.ada/excep_handle.exp: Likewise.
* gdb.ada/expr_delims.exp: Likewise.
* gdb.ada/expr_with_funcall.exp: Likewise.
* gdb.ada/exprs.exp: Likewise.
* gdb.ada/fin_fun_out.exp: Likewise.
* gdb.ada/fixed_cmp.exp: Likewise.
* gdb.ada/formatted_ref.exp: Likewise.
* gdb.ada/frame_arg_lang.exp: Likewise.
* gdb.ada/frame_args.exp: Likewise.
* gdb.ada/fullname_bp.exp: Likewise.
* gdb.ada/fun_addr.exp: Likewise.
* gdb.ada/fun_in_declare.exp: Likewise.
* gdb.ada/fun_overload_menu.exp: Likewise.
* gdb.ada/fun_renaming.exp: Likewise.
* gdb.ada/funcall_char.exp: Likewise.
* gdb.ada/funcall_param.exp: Likewise.
* gdb.ada/funcall_ptr.exp: Likewise.
* gdb.ada/funcall_ref.exp: Likewise.
* gdb.ada/homonym.exp: Likewise.
* gdb.ada/info_addr_mixed_case.exp: Likewise.
* gdb.ada/info_auto_lang.exp: Likewise.
* gdb.ada/info_exc.exp: Likewise.
* gdb.ada/info_types.exp: Likewise.
* gdb.ada/int_deref.exp: Likewise.
* gdb.ada/interface.exp: Likewise.
* gdb.ada/iwide.exp: Likewise.
* gdb.ada/lang_switch.exp: Likewise.
* gdb.ada/length_cond.exp: Likewise.
* gdb.ada/maint_with_ada.exp: Likewise.
* gdb.ada/mi_catch_assert.exp: Likewise.
* gdb.ada/mi_catch_ex.exp: Likewise.
* gdb.ada/mi_catch_ex_hand.exp: Likewise.
* gdb.ada/mi_dyn_arr.exp: Likewise.
* gdb.ada/mi_ex_cond.exp: Likewise.
* gdb.ada/mi_exc_info.exp: Likewise.
* gdb.ada/mi_interface.exp: Likewise.
* gdb.ada/mi_prot.exp: Likewise.
* gdb.ada/mi_ref_changeable.exp: Likewise.
* gdb.ada/mi_string_access.exp: Likewise.
* gdb.ada/mi_task_arg.exp: Likewise.
* gdb.ada/mi_task_info.exp: Likewise.
* gdb.ada/mi_var_array.exp: Likewise.
* gdb.ada/mi_var_union.exp: Likewise.
* gdb.ada/mi_variant.exp: Likewise.
* gdb.ada/minsyms.exp: Likewise.
* gdb.ada/mod_from_name.exp: Likewise.
* gdb.ada/nested.exp: Likewise.
* gdb.ada/null_array.exp: Likewise.
* gdb.ada/optim_drec.exp: Likewise.
* gdb.ada/out_of_line_in_inlined.exp: Likewise.
* gdb.ada/packed_array_assign.exp: Likewise.
* gdb.ada/packed_tagged.exp: Likewise.
* gdb.ada/pp-rec-component.exp: Likewise.
* gdb.ada/print_chars.exp: Likewise.
* gdb.ada/print_pc.exp: Likewise.
* gdb.ada/ptr_typedef.exp: Likewise.
* gdb.ada/ptype_arith_binop.exp: Likewise.
* gdb.ada/ptype_array.exp: Likewise.
* gdb.ada/ptype_field.exp: Likewise.
* gdb.ada/ptype_tagged_param.exp: Likewise.
* gdb.ada/ptype_union.exp: Likewise.
* gdb.ada/py_range.exp: Likewise.
* gdb.ada/py_taft.exp: Likewise.
* gdb.ada/rdv_wait.exp: Likewise.
* gdb.ada/rec_comp.exp: Likewise.
* gdb.ada/rec_return.exp: Likewise.
* gdb.ada/ref_param.exp: Likewise.
* gdb.ada/ref_tick_size.exp: Likewise.
* gdb.ada/rename_subscript_param.exp: Likewise.
* gdb.ada/repeat_dyn.exp: Likewise.
* gdb.ada/same_component_name.exp: Likewise.
* gdb.ada/same_enum.exp: Likewise.
* gdb.ada/scalar_storage.exp: Likewise.
* gdb.ada/set_wstr.exp: Likewise.
* gdb.ada/small_reg_param.exp: Likewise.
* gdb.ada/str_binop_equal.exp: Likewise.
* gdb.ada/str_ref_cmp.exp: Likewise.
* gdb.ada/str_uninit.exp: Likewise.
* gdb.ada/sub_variant.exp: Likewise.
* gdb.ada/sym_print_name.exp: Likewise.
* gdb.ada/taft_type.exp: Likewise.
* gdb.ada/tagged.exp: Likewise.
* gdb.ada/tagged_access.exp: Likewise.
* gdb.ada/task_bp.exp: Likewise.
* gdb.ada/task_switch_in_core.exp: Likewise.
* gdb.ada/tasks.exp: Likewise.
* gdb.ada/tick_last_segv.exp: Likewise.
* gdb.ada/tick_length_array_enum_idx.exp: Likewise.
* gdb.ada/type_coercion.exp: Likewise.
* gdb.ada/unc_arr_ptr_in_var_rec.exp: Likewise.
* gdb.ada/unchecked_union.exp: Likewise.
* gdb.ada/uninitialized_vars.exp: Likewise.
* gdb.ada/var_arr_attrs.exp: Likewise.
* gdb.ada/var_arr_typedef.exp: Likewise.
* gdb.ada/var_rec_arr.exp: Likewise.
* gdb.ada/variant-record.exp: Likewise.
* gdb.ada/variant.exp: Likewise.
* gdb.ada/variant_record_packed_array.exp: Likewise.
* gdb.ada/varsize_limit.exp: Likewise.
* gdb.ada/whatis_array_val.exp: Likewise.
* gdb.ada/widewide.exp: Likewise.
* gdb.ada/win_fu_syms.exp: Likewise.

[ARM, sim] Fix build failure with -Werror (PR26365)

There is a bit of a situation in the ARM sim with regards to the handling
of argv. sim_open () gets a const char **argv, but ARM's sim_open gets
clever and decides to modify argv in place via sim_target_parse_command_line.
I'm not sure why.

In any case, here's a fix that makes the code modify a copy of argv instead.

sim/arm/ChangeLog:

2020-08-13  Luis Machado  <luis.machado@linaro.org>

PR sim/26365

* wrapper.c (sim_target_parse_command_line): Free discarded argv
entries.
(sim_open): Use a duplicate of argv instead of the original argv.

gdb: allow specifying multiple filters when running selftests

I found myself wanting to run a few specific selftests while developing.
I thought it would be nice to be able to provide multiple test names
when running `maintenant selftests`.  The arguments to that command is
currently interpreted as a single filter (not split by spaces), it now
becomes a list a filters, split by spaces.  A test is executed when it
matches at least one filter.

Here's an example of the result in GDB:

    (gdb) maintenance selftest xml
    Running selftest xml_escape_text.
    Running selftest xml_escape_text_append.
    Ran 2 unit tests, 0 failed
    (gdb) maintenance selftest xml unord
    Running selftest unordered_remove.
    Running selftest xml_escape_text.
    Running selftest xml_escape_text_append.
    Ran 3 unit tests, 0 failed
    (gdb) maintenance selftest xml unord foobar
    Running selftest unordered_remove.
    Running selftest xml_escape_text.
    Running selftest xml_escape_text_append.
    Ran 3 unit tests, 0 failed

Since the selftest machinery is also shared with gdbserver, I also
adapted gdbserver.  It accepts a `--selftest` switch, which accepts an
optional filter argument.  I made it so you can now pass `--selftest`
multiple time to add filters.

It's not so useful right now though: there's only a single selftest
right now in GDB and it's for an architecture I can't compile.  So I
tested by adding dummy tests, here's an example of the result:

    $ ./gdbserver --selftest=foo
    Running selftest foo.
    foo
    Running selftest foobar.
    foobar
    Ran 2 unit tests, 0 failed
    $ ./gdbserver --selftest=foo --selftest=bar
    Running selftest bar.
    bar
    Running selftest foo.
    foo
    Running selftest foobar.
    foobar
    Ran 3 unit tests, 0 failed

gdbsupport/ChangeLog:

* selftest.h (run_tests): Change parameter to array_view.
* selftest.c (run_tests): Change parameter to array_view and use
it.

gdb/ChangeLog:

* maint.c (maintenance_selftest): Split args and pass array_view
to run_tests.

gdbserver/ChangeLog:

* server.cc (captured_main): Accept multiple `--selftest=`
options.  Pass all `--selftest=` arguments to run_tests.

Change-Id: I422bd49f08ea8095ae174c5d66a2dd502a59613a

Fix an internal compiler error when attempting to create a second $GDB_DEBUG$ section.

PR 26359
* config/obj-som.c (obj_som_init_stab_section): Do nothing if the
$GDB_DEBUG$ section has already been created.

Obsolete ia64

* config.bfd: Obsolete ia64*-*-*.

Obsolete arm-symbianelf

* config.bfd: Obsolete arm*-*-symbianelf*.

Automatic date update in version.in

PowerPC64 --no-pcrel-optimize

This new option effectively ignores R_PPC64_PCREL_OPT, disabling the
optimization of instructions marked by that relocation.  The patch
also disables GOT indirect to GOT/TOC pointer relative code editing
when --no-toc-optimize.

bfd/
* elf64-ppc.h (struct ppc64_elf_params): Add no_pcrel_opt.
* elf64-ppc.c (ppc64_elf_relocate_section): Disable GOT reloc
optimizations when --no-toc-optimize.  Disable R_PPC64_PCREL_OPT
optimization when --no-pcrel-optimize.
ld/
* emultempl/ppc64elf.em (params): Init new field.
(enum ppc64_opt): Add OPTION_NO_PCREL_OPT.
(PARSE_AND_LIST_LONGOPTS, PARSE_AND_LIST_OPTIONS),
(PARSE_AND_LIST_ARGS_CASES): Support --no-pcrel-optimize.

PR26348, Malloc error in write_zeros

This adds a few more sanity checks on ELF objects, and a BFD flag to
disable objcopy and strip when fuzzed input files belong in the "too
hard" basket.

bfd/
PR 26348
* bfd.c (struct bfd): Add read_only.
* elfcode.h (elf_swap_shdr_in): Test both sh_offset and sh_size.
Set read_only on warning.
(elf_object_p): Sanity check program header alignment.  Set
read_only on warning.
* bfd-in2.h: Regenerate.
binutils/
PR 26348
* objcopy.c (copy_object): Report file name with endian error.
Error and return on abfd->read_only.

Fix malloc allocation size sanity check

During debugging of PR26362, it was noticed that the malloc size check
in check_type_length_before_alloc wasn't detecting an allocation attempt
of a huge amount of bytes, making GDB run into an internal error.

This happens because we're using an int to store a type's length. When the
type length is large enough, the int will overflow and the max_value_size
check won't work anymore.

The following patch fixes this by making the length variable a ULONGEST.

Printing statements were also updated to show the correct number of bytes.

gdb/ChangeLog:

2020-08-12  Luis Machado  <luis.machado@linaro.org>

* value.c (check_type_length_before_alloc): Use ULONGEST to store a
type's length.
Use %s and pulongest to print the length.

Move multi-target NEWS entry to GDB 10 features

Simon noticed that I managed to put this in the "Changes in GDB 9"
section by mistake instead of in the "Changes since GDB 9" section
where it belongs.

gdb/ChangeLog:

* NEWS: Move "Multi-target debugging support" item to the
"Changes since GDB 9" section.

gdb.base/corefile.exp regression for unix/-m32 on x86_64 (PR 26336)

gdb.base/corefile.exp is showing an unexpected failure and an
unresolved testcase when testing against unix/-m32:

 (gdb) PASS: gdb.base/corefile.exp: attach: sanity check we see the core file
 attach 15741
 gdb/dwarf2-frame.c:1009: internal-error: dwarf2_frame_cache* dwarf2_frame_cache(frame_info*, void**): Assertion `fde != NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.base/corefile.exp: attach: with core (GDB internal error)
 Resyncing due to internal error.

This regressed with:

 From 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2 Mon Sep 17 00:00:00 2001
 From: Pedro Alves <palves@redhat.com>
 Date: Fri, 10 Jan 2020 20:06:08 +0000
 Subject: [PATCH] Multi-target support

The assertion is here:

 #0  internal_error (file=0xbffffccb0 <error: Cannot access memory at address 0xbffffccb0>, line=0, fmt=0x555556327320 "en_US.UTF-8") at sr
 c/gdbsupport/errors.cc:51
 #1  0x00005555557d4e45 in dwarf2_frame_cache (this_frame=0x55555672f950, this_cache=0x55555672f968) at src/gdb/dwarf2/frame.c:1013
 #2  0x00005555557d5886 in dwarf2_frame_this_id (this_frame=0x55555672f950, this_cache=0x55555672f968, this_id=0x55555672f9b0) at src/gdb/d
 warf2/frame.c:1226
 #3  0x00005555558b184e in compute_frame_id (fi=0x55555672f950) at src/gdb/frame.c:558
 #4  0x00005555558b19b2 in get_frame_id (fi=0x55555672f950) at src/gdb/frame.c:588
 #5  0x0000555555bda338 in scoped_restore_current_thread::scoped_restore_current_thread (this=0x7fffffffd0d8) at src/gdb/thread.c:1458
 #6  0x00005555556ce41f in scoped_restore_current_pspace_and_thread::scoped_restore_current_pspace_and_thread (During symbol reading: .debug_line address at offset 0x1db2d3
 is 0 [in module /home/pedro/gdb/cascais-builds/binutils-gdb/gdb/gdb]
 this=0x7fffffffd0d0) at src/gdb/progspace-and-thread.h:29
 #7  0x0000555555898ea6 in remove_target_sections (owner=0x555556935550) at src/gdb/exec.c:798
 #8  0x0000555555b700b6 in symfile_free_objfile (objfile=0x555556935550) at src/gdb/symfile.c:3742
 #9  0x000055555565050e in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd190
 : 0x555556935550) at /usr/include/c++/9/bits/std_function.h:300
 #10 0x0000555555a3053d in std::function<void (objfile*)>::operator()(objfile*) const (this=0x555556752a20, __args#0=0x555556935550) at /usr/include/c++/9/bits/std_function.
 h:688
 #11 0x0000555555a2ff01 in gdb::observers::observable<objfile*>::notify (this=0x5555562eaa80 <gdb::observers::free_objfile>, args#0=0x555556935550) at /net/cascais.nfs/gdb/b
 inutils-gdb/src/gdb/../gdbsupport/observable.h:106
 #12 0x0000555555a2c56a in objfile::~objfile (this=0x555556935550, __in_chrg=<optimized out>) at src/gdb/objfiles.c:521
 #13 0x0000555555a31d46 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c1f6f0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
 #14 0x00005555556d3444 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c1f6f0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
 #15 0x00005555556cec77 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556b99ee8, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
 #16 0x0000555555a2f8da in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556b99ee0, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
 #17 0x0000555555a2f8fa in std::shared_ptr<objfile>::~shared_ptr (this=0x555556b99ee0, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
 #18 0x0000555555a63fba in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x55555679f0c0, __p=0x555556b99ee0) at /usr/include/c++/9/ext/new_allocator.h:153
 #19 0x0000555555a638fb in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556b99ee0) at /usr/include/c++/9/bits/alloc_traits.h:497
 #20 0x0000555555a6351c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x55555679f0c0, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556935550}) at /usr/include/c++/9/bits/stl_list.h:1921
 #21 0x0000555555a62dab in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x55555679f0c0, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556935550}) at /usr/include/c++/9/bits/list.tcc:158
 #22 0x0000555555a614dd in program_space::remove_objfile (this=0x55555679f080, objfile=0x555556935550) at src/gdb/progspace.c:207
 #23 0x0000555555a2c4dc in objfile::unlink (this=0x555556935550) at src/gdb/objfiles.c:497
 #24 0x0000555555a2da65 in objfile_purge_solibs () at src/gdb/objfiles.c:904
 #25 0x0000555555b3af74 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
 #26 0x0000555555bbafc7 in target_pre_inferior (from_tty=1) at src/gdb/target.c:1900
 #27 0x0000555555940afb in attach_command (args=0x5555563277c7 "15741", from_tty=1) at src/gdb/infcmd.c:2582
 ...

The problem is that the multi-target commit added a
scoped_restore_current_thread to remove_target_sections (frame #7
above).  scoped_restore_current_thread's ctor fetches the selected
frame's frame id.  If the frame had not had its frame id computed yet,
it is computed then (frame #4 above).  Because it has been determined
earlier that the frame's unwinder is the DWARF unwinder, we end up
here:

 static struct dwarf2_frame_cache *
 dwarf2_frame_cache (struct frame_info *this_frame, void **this_cache)
 {
 ...
   /* Find the correct FDE.  */
   fde = dwarf2_frame_find_fde (&pc1, &cache->per_objfile);
   gdb_assert (fde != NULL);

And, that assertion fails.  The assertion is reasonable, because the
DWARF unwinder only claims the frame if it managed to find the FDE
earlier (in dwarf2_frame_sniffer).

(unix/-m32 is thus really a red herring here -- it's just that on
x86_64 -m64, the frame is not claimed by the DWARF unwinder.)

The reason the assertion is failing, is because the objfile that
contains the FDE has been removed from the objfiles list already when
we get here (frame #22 above).  This suggests that the fix should be
to invalidate DWARF frames when their objfile is removed.  Or to keep
it simple and safe, invalidate the frame cache when an objfile is
removed.  That is what this commit does.

OOC, I checked why is it that when you unload a file with plain "(gdb)
file", we don't hit the assertion.  It must be because we're already
flushing the frame cache somewhere else in that case.  And indeed, we
flush the frame cache here:

 (gdb) bt
 #0  reinit_frame_cache () at src/gdb/frame.c:1857
 #1  0x0000555555ad1ad6 in registers_changed_ptid (target=0x0, ptid=...) at src/gdb/regcache.c:470
 #2  0x0000555555ad1b58 in registers_changed () at src/gdb/regcache.c:485
 #3  0x00005555558d095e in set_target_gdbarch (new_gdbarch=0x555556d5f5b0) at src/gdb/gdbarch.c:5528
 #4  0x0000555555677175 in set_gdbarch_from_file (abfd=0x0) at src/gdb/arch-utils.c:601
 #5  0x0000555555897c6b in exec_file_attach (filename=0x0, from_tty=1) at src/gdb/exec.c:409
 #6  0x000055555589852d in exec_file_command (args=0x0, from_tty=1) at src/gdb/exec.c:571
 #7  0x00005555558985a1 in file_command (arg=0x0, from_tty=1) at src/gdb/exec.c:583
 #8  0x000055555572b55f in do_const_cfunc (c=0x55555672e200, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:95
 #9  0x000055555572f3d3 in cmd_func (cmd=0x55555672e200, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2181
 #10 0x0000555555be1ecc in execute_command (p=0x555556327804 "", from_tty=1) at src/gdb/top.c:668
 #11 0x0000555555895427 in command_handler (command=0x555556327800 "file") at src/gdb/event-top.c:588
 #12 0x00005555558958af in command_line_handler (rl=...) at src/gdb/event-top.c:773
 #13 0x0000555555894b3e in gdb_rl_callback_handler (rl=0x55555a09e240 "file") at src/gdb/event-top.c:219
 #14 0x0000555555ccfeec in rl_callback_read_char () at src/readline/readline/callback.c:281
 #15 0x000055555589495a in gdb_rl_callback_read_char_wrapper_noexcept () at src/gdb/event-top.c:177
 #16 0x0000555555894a08 in gdb_rl_callback_read_char_wrapper (client_data=0x555556327520) at src/gdb/event-top.c:194
 #17 0x00005555558952a5 in stdin_event_handler (error=0, client_data=0x555556327520) at src/gdb/event-top.c:516
 #18 0x0000555555e027d6 in handle_file_event (file_ptr=0x555558d20840, ready_mask=1) at src/gdbsupport/event-loop.cc:548
 #19 0x0000555555e02d88 in gdb_wait_for_event (block=1) at src/gdbsupport/event-loop.cc:673
 #20 0x0000555555e01c42 in gdb_do_one_event () at src/gdbsupport/event-loop.cc:215
 #21 0x00005555559c47c2 in start_event_loop () at src/gdb/main.c:356
 #22 0x00005555559c490d in captured_command_loop () at src/gdb/main.c:416
 #23 0x00005555559c6217 in captured_main (data=0x7fffffffdc00) at src/gdb/main.c:1253
 #24 0x00005555559c6289 in gdb_main (args=0x7fffffffdc00) at src/gdb/main.c:1268
 #25 0x0000555555621756 in main (argc=3, argv=0x7fffffffdd18) at src/gdb/gdb.c:32

gdb/ChangeLog:

PR gdb/26336
* progspace.c (program_space::remove_objfile): Invalidate the
frame cache.

[PATCH] gas: arm: Fix IT-predicated MVE vcvt

* config/tc-arm.c (do_neon_cvt_1): Parse vcvtne as vcvt-ne for
NS_FD shape when MVE is present
* testsuite/gas/arm/mve-vcvtne-it-bad.d: New test.
* testsuite/gas/arm/mve-vcvtne-it-bad.l: New test.
* testsuite/gas/arm/mve-vcvtne-it-bad.s: New test.
* testsuite/gas/arm/mve-vcvtne-it.d: New test.
* testsuite/gas/arm/mve-vcvtne-it.s: New test.

Fix signedness comparison warning in elfcore_grok_win32pstatus()

bfd/ChangeLog:

2020-08-12  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Use unsigned int for
win32pstatus note type to avoid signedness comparison warning.

Two fixes in dwarf-mode.el

This fixes a couple of small problems in dwarf-mode.el.

First, I noticed that for an attribute like:

 <2><136c>: Abbrev Number: 11 (DW_TAG_member)
    <136d>   DW_AT_name        : t

... the "t" would not be font-locked using the function name face.
The problem here is that the regexp assumed the indirect string
format, like:

    <12ac>   DW_AT_name        : (indirect string, offset: 0x1b40): whatever

Here the fix is to adjust the regexp to match both formats.

Second, when following a DIE reference, point could end up on an
attribute instead.  This happens when there is a zero-length attribute
with the same "offset" as the following DIE, like:

    <12c5>   DW_AT_GNU_all_call_sites: 1
 <2><12c5>: Abbrev Number: 5 (DW_TAG_formal_parameter)

Here the fix is to search for the DIE by looking for the depth ("<2>"
in the example) as well.

I've bumped the internal version number to make it simpler to install
this using the Emacs package facility.

binutils/ChangeLog
2020-08-12  Tom Tromey  <tromey@adacore.com>

* dwarf-mode.el (Version): Now 1.6.
(dwarf-die-button-action): Tighten DIE reference regexp.
(dwarf-font-lock-keywords): Update name regexp.

Only warn about malformed win32pstatus notes

bfd/ChangeLog:

2020-07-21  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Warn on malformed
win32pstatus notes, and return TRUE so we continue rather than
stopping as if it was an error.

Add handling for 64-bit module addresses in Cygwin core dumps

bfd/ChangeLog:

2020-07-01  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Handle NOTE_INFO_MODULE64.

Refine size constraints applied to win32pstatus ELF notes

Don't reject any win32pstatus notes smaller than minimum size for a
NOTE_INFO_THREAD.

This only happens to work because the Cygwin dumper tool currently
writes all these notes as the largest size of the union, (which wastes
lots of space in the core dump).

Instead, apply the appropriate size constraint for each win32pstatus
note type.

bfd/ChangeLog:

2020-07-11  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Don't apply size constraint
for NOTE_INFO_THREAD to all win32pstatus ELF notes, instead apply
appropriate size constraint for each win32pstatus note type.

Don't hardcode CONTEXT size for a NOTE_INFO_THREAD win32pstatus note

Don't hardcode the size of the Win32 API thread CONTEXT type read from a
NOTE_INFO_THREAD win32pstatus note (since it's different on different
architectures).

bfd/ChangeLog:

2020-07-01  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Don't hardcode the size of
the Win32 API thread CONTEXT type read from a NOTE_INFO_THREAD
win32pstatus note.

Define constants for win32pstatus ELF notes

Define constants for win32pstatus ELF notes, as they were prior to
4a6636fb, and say what specifies them.

bfd/ChangeLog:

2020-07-11  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (NOTE_INFO{_PROCESS,_THREAD,_MODULE}): Define.
(elfcore_grok_win32pstatus): Use.

Read tid from correct offset in win32pstatus NOTE_INFO_THREAD

Fix the offset used to read the tid from a win32pstatus ELF note.

This probably meant that registers were only being correctly recovered
from the core dump for the current thread.

It looks like this has beeen incorrect since 4a6636fb.

Also fix offsets used in NOTE_INFO_PROCESS (which is not actually
generated by the Cygwin dumper tool).

Also improve comment.

bfd/ChangeLog:

2020-07-01  Jon Turney  <jon.turney@dronecode.org.uk>

* elf.c (elfcore_grok_win32pstatus): Fix the offset used to read
the tid from a win32pstatus NOTE_INFO_THREAD ELF note.  Fix
offsets used to read NOTE_INFO_PROCESS.

Fix duplicate label in gdb.dwarf2/dw2-op-out-param.S

gdb.dwarf2/dw2-op-out-param.S contained a duplicate label, and failed
to build with clang with the following error:

 gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.dwarf2/dw2-op-out-param.S:163:1:
       error: invalid symbol redefinition
 .Ltext5:
 ^

This commit renames the two labels as .Ltext5a and .Ltext5b, and
updates all references appropriately.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/dw2-op-out-param.S (.Ltext5): Fix duplicate label.

aarch64: Add support for MPAM system registers

This patch adds support for the system registers introduced in the
Armv8-A MPAM extension.

See https://developer.arm.com/documentation/ddi0598/latest for the
Arm ARM supplement documenting this extension.

gas/ChangeLog:

* testsuite/gas/aarch64/mpam-bad.d: New test.
* testsuite/gas/aarch64/mpam-bad.l: Error output.
* testsuite/gas/aarch64/mpam-bad.s: Input.
* testsuite/gas/aarch64/mpam.d: New test.
* testsuite/gas/aarch64/mpam.s: Input.

opcodes/ChangeLog:

* aarch64-opc.c (aarch64_sys_regs): Add MPAM registers.

The description for -mno-csr-check talks about "cheching" rather than "checking".

PR 26346
* doc/c-riscv.texi (RISC-V-Options): Fix typo in the description
of the -mno-csr-check option.

Add demangling support to readelf.

PR binutils/26331
* readelf.c (do_demangle): New option flag.
(print_symbol): If do_demangle is enabled, demangle the symbol.
(enum long_option_values): New enum to hold long option values.
(options): Add demangle, no-demangle, recursion-limit and
no-recursion-limit options.  Alpha sort the table.
(usage): Describe the new options.
(parse_args): Handle the new options.
* NEWS: Mention the new feature.
* doc/binutils.texi: Document the new feature.
* testsuite/binutils-all/readelf.exp: Test the new feature.
* testsuite/binutils-all/mangled.s: New file - assembler source.
* testsuite/binutils-all/readelf.demangled: New file - expected
output from readelf.

Updated Serbian and Russian translations for various sub-directories

Automatic date update in version.in

PowerPC CELL cctp*

* ppc-opc.c (powerpc_opcodes): Move cctpl, cctpm and cctph.

[gdb/build] Mark ms1 as deleted in MAINTAINERS

When running gdb/gdb_mbuild.sh, we run into:
...
ms1-elf ...
... src/configure --target=ms1-elf --enable-gdb-build-warnings=,-Werror \
  --enable-sim-build-warnings=,-Werror
... make -k -j 5 ms1-elf
ms1-elf: compile failed
...

In mbuild/ms1-elf/Build.log we find:
...
*** Configuration mt-unknown-elf is obsolete.
*** Support has been REMOVED.
make: *** [Makefile:10995: configure-gdb] Error 1
...

The support for ms1-elf, aka mt-elf, has been removed since commit dc71152484
"Remove mt port" in Jan 2018.  Make this official in the MAINTAINERS file.

Tested using gdb/gdb_mbuild.sh.

gdb/ChangeLog:

2020-08-11  Tom de Vries  <tdevries@suse.de>

* MAINTAINERS: Mark ms1 as deleted.

Automatic date update in version.in

aarch64: Don't assert on long sysreg names

This patch fixes an assertion failure on long system register operands
in the AArch64 backend. See the new testcase for an input which
reproduces the issue.

gas/ChangeLog:

* config/tc-aarch64.c (parse_sys_reg): Don't assert when parsing
a long system register.
(parse_sys_ins_reg): Likewise.
(sysreg_hash_insert): New.
(md_begin): Use sysreg_hash_insert() to ensure all system
registers are no longer than the maximum length at startup.
* testsuite/gas/aarch64/invalid-sysreg-assert.d: New test.
* testsuite/gas/aarch64/invalid-sysreg-assert.l: Error output.
* testsuite/gas/aarch64/invalid-sysreg-assert.s: Input.

include/ChangeLog:

* opcode/aarch64.h (AARCH64_MAX_SYSREG_NAME_LEN): New.

Remove spurious text in changelog entry

Improve the documentation of the linker's --relax option.

PR ld/21351
* ld.texi: Clarify the behaviour of the --relax and --no-relax
options on systems that do not support them.

[sim] Fix mbuild build breaker in sim-cpu.c

When running gdb/gdb_mbuild.sh, I run into:
...
src/sim/aarch64/../common/sim-cpu.c: In function 'sim_cpu_free':
src/sim/aarch64/../common/sim-cpu.c:64:3: error: implicit declaration of \
  function 'free' [-Werror=implicit-function-declaration]
   free (cpu);
   ^~~~
src/sim/aarch64/../common/sim-cpu.c:64:3: error: incompatible implicit \
  declaration of built-in function 'free' [-Werror]
src/sim/aarch64/../common/sim-cpu.c:64:3: note: include '<stdlib.h>' or \
  provide a declaration of 'free'
...

Fix this by adding "#include <stdlib.h>".

Tested by gdb/gdb_mbuild.sh -e aarch64-elf.

sim/common/ChangeLog:

2020-08-10  Tom de Vries  <tdevries@suse.de>

* sim-cpu.c: Include stdlib.h for free.

[aarch64] GAS doesn't validate the architecture version for any tlbi registers.  Fixed with this patch.

* gas/config/tc-aarch64.c (parse_sys_reg): Call to
aarch64_sys_ins_reg_supported_p instead of aarch64_sys_reg_supported_p.
(parse_sys_ins_reg): Add aarch64_sys_reg_deprecated_p check.
* include/opcode/aarch64.h (aarch64_sys_reg_deprecated_p): Functions
paramaters changed.
(aarch64_sys_reg_supported_p): Function removed.
(aarch64_sys_ins_reg_supported_p): Functions paramaters changed.
* opcodes/aarch64-opc.c (aarch64_print_operand):
(aarch64_sys_reg_deprecated_p): Functions paramaters changed.
(aarch64_sys_reg_supported_p): Function removed.
(aarch64_sys_ins_reg_supported_p): Functions paramaters changed.
(aarch64_sys_ins_reg_supported_p): Merged aarch64_sys_reg_supported_p
into this function.
* gas/testsuite/gas/aarch64/illegal-sysreg-5.d: New test.
* gas/testsuite/gas/aarch64/illegal-sysreg-5.l: New test.
* gas/testsuite/gas/aarch64/sysreg-5.s: New test.

[AArch64] Improve prologue handling (and fix PR26310)

I initially noticed the problem with the addition of
gdb.dwarf2/dw2-line-number-zero.exp.  The following failures showed up:

FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next

They happen because AArch64's prologue analyzer skips too many instructions
and ends up indicating a stopping point further into user code.

Dump of assembler code for function bar1:
   0x00000000000006f8 <+0>: stp x29, x30, [sp, #-16]!
   0x00000000000006fc <+4>: mov x29, sp
   0x0000000000000700 <+8>: mov w0, #0x1                    // #1
   0x0000000000000704 <+12>: bl 0x6e4 <foo>
   0x0000000000000708 <+16>: mov w0, #0x2                    // #2

We should've stopped at 0x700, but the analyzer actually skips
that instruction and stops at 0x704.  Then GDB ends up adjusting
the address further, and pushes the stopping point to 0x708 based on the
SAL information.

I'm not sure if this adjustment to 0x708 is correct though, as it ends up
skipping past a branch. But I'm leaving that aside for now.

One other complicating factor is that GCC seems to be hoisting up instructions
from user code, mixing them up with prologue instructions.

The following patch adjusts the heuristics a little bit, and tracks when the
SP and FP get used.  If we notice an instruction that is not supposed to be
in the prologue, and this happens *after* SP/FP adjustments and saving of
registers, we stop the analysis.

This means, for PR26310, that we will now stop at 0x700.

I've also added a few more unit tests to make sure the updated behavior is
validated.

gdb/ChangeLog:

2020-08-10  Luis Machado  <luis.machado@linaro.org>

PR gdb/26310

* aarch64-tdep.c (aarch64_analyze_prologue): Track use of SP/FP and
act accordingly.
(aarch64_analyze_prologue_test): Add more unit tests to exercise
movz/str/stur/stp skipping behavior.

[AArch64] Fix incorrectly-defined SVE macro

The kernel has fixed this here:

https://lore.kernel.org/patchwork/patch/1029011/

We should do the same for GDB, which is still carrying an incorrect
definition of the macro.  As stated in the kernel patch thread, this doesn't
actually change things because, luckily, the structs are of the same size.

gdb/ChangeLog:

2020-08-10  Luis Machado  <luis.machado@linaro.org>

* nat/aarch64-sve-linux-sigcontext.h (SVE_PT_REGS_OFFSET): Use
struct user_sve_header instead of struct sve_context.

Implement missing powerpc mtspr and mfspr extended insns

* ppc-opc.c (powerpc_opcodes): Add many mtspr and mfspr extended
instructions.

Implement missing powerpc extended mnemonics

gas/
* testsuite/gas/ppc/power8.d,
* testsuite/gas/ppc/power8.s: Add miso.
* testsuite/gas/ppc/power9.d,
* testsuite/gas/ppc/power8.s: Add exser, msgsndu, msgclru.
opcodes/
* ppc-opc.c (powerpc_opcodes): Add exser, msgsndu, msgclru.
Enable icbt for power5, miso for power8.

Prioritise mtfprd and mtvrd over mtvsrd in PowerPC disassembly

gas/
* testsuite/gas/ppc/power8.d: Update.
* testsuite/gas/ppc/vsx2.d: Update.
opcodes/
* ppc-opc.c (powerpc_opcodes): Prioritise mtfprd and mtvrd over
mtvsrd, and similarly for mfvsrd.

Error on lmw, lswi and related PowerPC insns when LE

* config/tc-ppc.c (md_assemble): Error for lmw, stmw, lswi, lswx,
stswi, or stswx in little-endian mode.
* testsuite/gas/ppc/476.d,
* testsuite/gas/ppc/476.s: Delete lmw, stmw, lswi, lswx, stswi, stswx.
* testsuite/gas/ppc/a2.d,
* testsuite/gas/ppc/a2.s: Move lmw, stmw, lswi, lswx, stswi, stswx..
* testsuite/gas/ppc/be.d,
* testsuite/gas/ppc/be.s: ..to here, new big-endian only test.
* testsuite/gas/ppc/le_error.d,
* testsuite/gas/ppc/le_error.l: New little-endian test.
* testsuite/gas/ppc/ppc.exp: Run new tests.

nm: Remove --with-symbol-versions

Since

commit 7e6e972f74aeac0ebdbd95a7f905d871cd2581de
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Mar 24 04:23:11 2020 -0700

    bfd: Display symbol version for nm -D

always displays symbol version for nm, remove --with-symbol-versions and
silently accept it for backward compatibility.

binutils/

PR binutils/26302
* nm.c (with_symbol_versions): Removed.
(long_option_values): Add OPTION_WITH_SYMBOL_VERSIONS.
(long_options): Update --with-symbol-versions entry.
(print_symbol): Remove the with_symbol_versions check.
(main): Add OPTION_WITH_SYMBOL_VERSIONS for backward
compatibility.
* doc/binutils.texi: Remove --with-symbol-versions.

ld/

PR binutils/26302
* testsuite/ld-elf/pr26302.nd: New file.
* testsuite/ld-elf/pr26302.ver: Likewise.
* testsuite/ld-elf/pr26302a.c: Likewise.
* testsuite/ld-elf/pr26302b.c: Likewise.
* testsuite/ld-elf/shared.exp: Run binutils/26302 tests.

Automatic date update in version.in

gdb: replace function pointer with `void *` data with function_view

Replace the function pointer + `void *` parameters of
dwarf2_fetch_die_loc_sect_off and dwarf2_fetch_die_loc_cu_off with a
function_view parameter.  Change call sites to use a lambda function.
This improves type-safety, so reduces the chances of errors.

gdb/ChangeLog:

* read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Replace function pointer +
`void *` parameter with function_view.
* read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Likewise.
* loc.c (get_frame_pc_for_per_cu_dwarf_call): Remove.
(per_cu_dwarf_call): Adjust.
(get_frame_address_in_block_wrapper): Remove.
(indirect_synthetic_pointer): Adjust.
(get_ax_pc): Remove.
(dwarf2_compile_expr_to_ax): Adjust.

Change-Id: Ic9b6ced0c4128f2b75ca62e0ed638b0962a22859

Automatic date update in version.in

[gdb/build] Fix missing implicit constructor call with gcc 4.8

When building gdb on x86_64-linux with --enable-targets riscv64-suse-linux, I
run into:
...
src/gdb/arch/riscv.c:112:45:   required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:195:39: error: no matching \
  function for call to 'std::pair<const riscv_gdbarch_features, const \
  std::unique_ptr<target_desc, target_desc_deleter> >::pair(const \
  riscv_gdbarch_features&, target_desc*&)'
  : _M_v(std::forward<_Args>(__args)...) { }
                                       ^
...
for this code in riscv_lookup_target_description:
...
  /* Add to the cache.  */
  riscv_tdesc_cache.emplace (features, tdesc);
...

Work around this compiler problem (filed as PR gcc/96537), similar to how that
was done in commit 6d0cf4464e "Fix build with gcc-4.8.x":
...
-  riscv_tdesc_cache.emplace (features, tdesc);
+  riscv_tdesc_cache.emplace (features, target_desc_up (tdesc));
...
That is, call the target_desc_up constructor explictly instead of implicitly.

Also, work around a similar issue in get_thread_arch_aspace_regcache.

Build on x86_64-linux with --enable-targets riscv64-suse-linux, and
reg-tested.

gdb/ChangeLog:

2020-08-08  Tom de Vries  <tdevries@suse.de>

PR build/26344
* arch/riscv.c (riscv_lookup_target_description): Use an explicit
constructor.
* regcache.c (get_thread_arch_aspace_regcache): Same.

Automatic date update in version.in

bpf: add missing tests from previous commits

2020-08-07  David Faust  <david.faust@oracle.com>

* testsuite/ld-bpf/call-3.s: New file.
* testsuite/ld-bpf/call-3.d: Likewise.

bpf: fix false overflow in eBPF ELF backend linker

When performing DISP{16,32} relocations, the eBPF ELF backend linker
needs to convert the relocation from an address into a signed number
of 64-bit words (minus one) to jump.

Because of this unsigned-to-signed conversion, special care needs to
be taken when dividing to ensure the sign bits remain correct.
Otherwise, a false relocation overflow error can be triggered.

bfd/ChangeLog

2020-08-07  David Faust  <david.faust@oracle.com>

* elf64-bpf.c (bpf_elf_relocate_section): Ensure signed division for
DISP16 and DISP32 relocations.

ld/ChangeLog

2020-08-07  David Faust  <david.faust@oracle.com>

* testsuite/ld-bpf/call-3.s: New file.
* testsuite/ld-bpf/call-3.d: Likewise.

gdb: fix whitespace issues in ChangeLog

Change-Id: Iea4bd2096bb994ec4ea9145cbe316aa345e8c6db

Fix remaining Ravenscar regressions

Testing showed a few more Ravenscar regressions arising from upstream.
In particular, gdb now uses the current thread in some places where
inferior_ptid was previously used.  This patch fixes the problem by
arranging to save and restore the thread now.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c
(ravenscar_thread_target::set_base_thread_from_ravenscar_task):
New method.
(ravenscar_thread_target::wait): Check
runtime_initialized.
(ravenscar_thread_target::prepare_to_store)
(ravenscar_thread_target::stopped_by_sw_breakpoint)
(ravenscar_thread_target::stopped_by_hw_breakpoint)
(ravenscar_thread_target::stopped_by_watchpoint)
(ravenscar_thread_target::stopped_data_address)
(ravenscar_thread_target::core_of_thread): Use
scoped_restore_current_thread and
set_base_thread_from_ravenscar_task.

Set inferior_ptid in ravenscar_thread_target::update_thread_list

Commit 2da4b788f ("Don't write to inferior_ptid in
ravenscar-thread.c") caused a Ravenscar regression (which, FWIW, is
understandable because Ravenscar is difficult to test).  Namely,
ravenscar_thread_target::update_thread_list calls
iterate_over_live_ada_tasks, which calls ada_build_task_list, which
uses target_has_stack -- which relies on inferior_ptid.

This patch changes update_thread_list to ensure that inferior_ptid is
set before making this call.  This avoids various failures on
Ravenscar targets.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (update_thread_list): Set inferior_ptid.

Fetch registers from correct thread in ravenscar-thread.c

Fabien also noticed that gdb would not report a stop correctly when
using Ravenscar.  This patch fixes the bug by making a few changes:

* ravenscar_thread_target::wait now updates the inferior ptid before
  updating the thread list.  This ensures that a new thread is
  correctly associated with the underlying CPU.

* The fetch_registers, store_registers, and prepare_to_store methods
  now save and restore the regcache's ptid before doing the operation
  on the underlying live thread.  This ensures that gdb informs the
  remote of a thread it knows about, as opposed to using a Ravenscar
  thread, which probably will not be recognized.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target::wait): Call
update_inferior_ptid before update_thread_list.
(temporarily_change_regcache_ptid): New class.
(ravenscar_thread_target::fetch_registers)
(ravenscar_thread_target::store_registers)
(ravenscar_thread_target::prepare_to_store): Use base thread when
forwarding operation.

Fix Ravenscar "process" resume

A coworker noticed that gdb would send the wrong vCont packet to qemu
when debugging a Ravenscar program:

    > (gdb) thread 2
    > [Switching to thread 2 (Thread 1.2)]
    > #0  0x0000000000001000 in ?? ()

    > (gdb) c
    [...]
    > Sending packet: $vCont;c:p1.1#e2...Ack

Here, we've switched to thread 2, but the packet says to resume thread
1.

This turned out to be a bug in ravenscar_thread_target::resume, which
did not properly handle the case of a "process" resume.  In
particular, the resume method would be passed a ptid of (1, 0, 0) --
but then rewrite this to its saved ptid.

This patch fixes the problem by recognizing this case in the resume
method.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target::resume): Handle
"is_pid" case.

Update Ravenscar documentation

This documents some recent Ravenscar changes, and further documents
the known limitation where stepping through the runtime initialization
code does not work properly.

gdb/doc/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (Ravenscar Profile): Add examples.
Document runtime initialization limitation.

Wrap xfer_partial and enable_btrace for Ravenscar

A gdb crash showed that the xfer_partial target method was not wrapped
for Ravenscar.  This caused remote.c to call
remote::set_general_thread with a Ravenscar "fake" ptid, which showed
up later as an event ptid.

I went through all the target methods and looked to see which ones
could call set_general_thread or set_continue_thread (but not
set_general_process, as I think Ravenscar targets aren't
multi-inferior).  This patch wraps the two that I found.

xfer_partial requires special treatment, because it can be called
recursively via get_base_thread_from_ravenscar_task.  To avoid a
recursive call, this patch changes update_thread_list to record all
tasks in the m_cpu_map, and changes get_thread_base_cpu to prefer this
map.  This avoids some memory reads.

It was unclear to me whether enable_btrace really makes sense for
Ravenscar; but at the same time it seemed harmless to add this patch.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (xfer_partial, enable_btrace, add_thread):
New methods.
(ravenscar_thread_target::get_thread_base_cpu): Check m_cpu_map
first.
(ravenscar_thread_target::add_thread): Rename from
ravenscar_add_thread.
(ravenscar_thread_target::update_thread_list): Use a lambda.
(ravenscar_thread_target::xfer_partial): New method.

Use gdb::function_view in iterate_over_live_ada_tasks

This changes iterate_over_live_ada_tasks to accept a
gdb::function_view.  This is needed by a subsequent patch.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ada-lang.h (ada_task_list_iterator_ftype): Now a
gdb::function_view.
(iterate_over_live_ada_tasks): Change type of argument.
* ada-tasks.c (iterate_over_live_ada_tasks): Change type
of argument.

Change names given to Ravenscar threads

Current a Ravenscar thread is given the same sort of name as a "CPU"
thread; they can only be distinguished by looking at the output of
"info thread".

This patch changes ravenscar-thread.c to distinguish these threads,
like:

    (gdb) continue
    Continuing.
    [New Ravenscar Thread 0x2b910]

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target) <extra_thread_info>:
Remove.
(ravenscar_thread_target::extra_thread_info): Remove.
(ravenscar_thread_target::pid_to_str): Mention Ravenscar in result;
defer to target beneath for non-Ravenscar threads.

Handle case where Ada task is current but not listed

Currently, the ravenscar runtime can mark an Ada task as the current
task, before adding it to the list of tasks that can be read by gdb.
In this scenario, gdb can sometimes crash in
ravenscar_get_thread_base_cpu with:

../../src/gdb/ravenscar-thread.c:167: internal-error: int ravenscar_get_thread_base_cpu(ptid_t): Assertion `task_info != NULL' failed.

However, as ravenscar_get_thread_base_cpu is only called to find the
base CPU, we can simply record this when registering the thread, and
look this up later.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target) <get_base_cpu,
get_base_thread_from_ravenscar_task>: Now methods.
<m_cpu_map>: New member.
(ravenscar_thread_target::get_thread_base_cpu): Rename from
ravenscar_get_thread_base_cpu.  Check m_cpu_map.
(ravenscar_thread_target::task_is_currently_active): Update.
(ravenscar_thread_target::get_base_thread_from_ravenscar_task):
Now a method.
(ravenscar_thread_target::add_active_thread): Put initial thread
into the m_cpu_map.

Return event_ptid from ravenscar_thread_target::wait

ravenscar_thread_target::wait should return the event ptid from the
wrapped "wait" call in the situation where returning the Ravenscar
thread ptid is not appropriate.  This probably does not really make a
difference in practice, but it seemed like a reasonable cleanup.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target::wait): Return
event_ptid.

Avoid crash in ravenscar_thread_target::wait

An earlier patch caused a Ravenscar regression in
ravenscar_thread_target::wait.  In particular, add_active_thread can
return NULL when the runtime is not initialized.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target::wait): Check
runtime_initialized.

Call add_active_thread after pushing the ravenscar target

Currently ravenscar-thread.c calls add_active_thread before pushing
the ravenscar target.  This yields an initial thread announcement of
"[Thread 0]".  Calling add_active_thread after pushing the target
fixes this.

gdb/ChangeLog
2020-08-07  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target): Don't call
add_active_thread.
(ravenscar_thread_target::add_active_thread): Now public.
(ravenscar_inferior_created): Call add_active_thread after pushing
the target.

gdb: change regcache list to be a map

One regcache object is created for each stopped thread and is stored in
the regcache::regcaches linked list.  Looking up a regcache for a given
thread is therefore in O(number of threads).  Stopping all threads then
becomes O((number of threads) ^ 2).  Same goes for resuming a thread
(need to delete the regcache of a given ptid) and resuming all threads.
It becomes noticeable when debugging thousands of threads, which is
typical with GPU targets.  This patch replaces the linked list with some
maps to reduce that complexity.

The first design was using an std::unordered_map with (target, ptid,
arch) as the key, because that's how lookups are done (in
get_thread_arch_aspace_regcache).  However, the registers_changed_ptid
function, also somewhat on the hot path (it is used when resuming
threads), needs to delete all regcaches associated to a given (target,
ptid) tuple.  If the key of the map is (target, ptid, arch), we have to
walk all items of the map, not good.

The second design was therefore using an std::unordered_multimap with
(target, ptid) as the key.  One key could be associated to multiple
regcaches, all with different gdbarches.  When looking up, we would have
to walk all these regcaches.  This would be ok, because there will
usually be actually one matching regcache.  In the exceptional
multi-arch thread cases, there will be maybe two.  However, in
registers_changed_ptid, we sometimes need to remove all regcaches
matching a given target.  We would then have to talk all items of the
map again, not good.

The design as implemented in this patch therefore uses two levels of
map.  One std::unordered_map uses the target as the key.  The value type
is an std::unordered_multimap that itself uses the ptid as the key.  The
values of the multimap are the regcaches themselves.  Again, we expect
to have one or very few regcaches per (target, ptid).

So, in summary:

* The lookups (in get_thread_arch_aspace_regcache), become faster when
  the number of threads grows, compared to the linked list.  With a
  small number of threads, it will probably be a bit slower to do map
  lookups than to walk a few linked list nodes, but I don't think it
  will be noticeable in practice.

* The function registers_changed_ptid deletes all regcaches related to a
  given (target, ptid).  It must now handle the different cases separately:

    - NULL target and minus_one_ptid: we delete all the entries
    - NULL target and non-minus_one_ptid: invalid (checked by assert)
    - non-NULL target and non-minus_one_ptid: we delete all the entries
      associated to that tuple
    - a non-NULL target and minus_one_ptid: we delete all the entries
      associated to that target

* The function regcache_thread_ptid_changed is called when a thread
  changes ptid.  It is implemented efficiently using the map, although
  that's not very important: it is not called often, mostly when
  creating an inferior, on some specific platforms.

This patch is a tiny bit from ROCm GDB [1] we would like to merge
upstream.  Laurent Morichetti gave be these performance numbers:

The benchmark used is:

  time ./gdb --data-directory=data-directory /extra/lmoriche/hip/samples/0_Intro/bit_extract/bit_extract -ex "set pagination off" -ex "set breakpoint pending on" -ex "b bit_extract_kernel if \$_thread == 5" -ex run -ex c -batch

It measures the time it takes to continue from a conditional breakpoint with
2048 threads at that breakpoint, one of them reporting the breakpoint.

baseline:
real    0m10.227s
real    0m10.177s
real    0m10.362s

with patch:
real    0m8.356s
real    0m8.424s
real    0m8.494s

[1] https://github.com/ROCm-Developer-Tools/ROCgdb

gdb/ChangeLog:

* regcache.c (ptid_regcache_map): New type.
(target_ptid_regcache_map): New type.
(regcaches): Change type to target_ptid_regcache_map.
(get_thread_arch_aspace_regcache): Update to regcaches' new
type.
(regcache_thread_ptid_changed): Likewise.
(registers_changed_ptid): Likewise.
(regcaches_size): Likewise.
(regcaches_test): Update.
(regcache_thread_ptid_changed): Update.
* regcache.h (regcache_up): New type.
* gdbsupport/ptid.h (hash_ptid): New struct.

Change-Id: Iabb0a1111707936ca111ddb13f3b09efa83d3402

gdb: pass target to thread_ptid_changed observable

I noticed what I think is a potential bug.  I did not observe it nor was
I able to reproduce it using actual debugging.  It's quite unlikely,
because it involves multi-target and ptid clashes.  I added selftests
that demonstrate it though.

The thread_ptid_changed observer says that thread with OLD_PTID now has
NEW_PTID.  Now, if for some reason we happen to have two targets
defining a thread with OLD_PTID, the observers don't know which thread
this is about.

regcache::regcache_thread_ptid_changed changes all regcaches with
OLD_PTID.  If there is a regcache for a thread with ptid OLD_PTID, but
that belongs to a different target, this regcache will be erroneously
changed.

Similarly, infrun_thread_ptid_changed updates inferior_ptid if
inferior_ptid matches OLD_PTID.  But if inferior_ptid currently refers
not to the thread is being changed, but to a thread with the same ptid
belonging to a different target, then inferior_ptid will erroneously be
changed.

This patch adds a `process_stratum_target *` parameter to the
`thread_ptid_changed` observable and makes the two observers use it.
Tests for both are added, which would fail if the corresponding fix
wasn't done.

gdb/ChangeLog:

* observable.h (thread_ptid_changed): Add parameter
`process_stratum_target *`.
* infrun.c (infrun_thread_ptid_changed): Add parameter
`process_stratum_target *` and use it.
(selftests): New namespace.
(infrun_thread_ptid_changed): New function.
(_initialize_infrun): Register selftest.
* regcache.c (regcache_thread_ptid_changed): Add parameter
`process_stratum_target *` and use it.
(regcache_thread_ptid_changed): New function.
(_initialize_regcache): Register selftest.
* thread.c (thread_change_ptid): Pass target to
thread_ptid_changed observable.

Change-Id: I0599e61224b6d154a7b55088a894cb88298c3c71

Add code for processing version 5 DWP files (for use with DWARF v5).

The DWARF v5 Spec describes a (slightly) new format for V5 .dwp files.
    This patch updates GDB to allow it to read/process .dwp files in the
    new DWARF v5 format, while continuing to be able to read/process .dwp files
    in the older V1 & V2 formats (older, pre-standard formats).

    The two major differences between the V2 and the V5 format are:
        - The inclusion of DWARF-v5-specific sections:
              .debug_loclists.dwo
              .debug_rnglists.dwo
        - The .dwp section identifier encodings have changed.  The table below
          shows the old & new encodings.  Notice the re-purposing of 5, 7 & 8
          in particular.

    Val  DW4 section       DW4 section id  DW5 section         DW5 section id
    --- -----------------  --------------  -----------------   --------------
     1  .debug_info.dwo    DW_SECT_INFO    .debug_info.dwo     DW_SECT_INFO
     2  .debug_types.dwo   DW_SECT_TYPES         --              reserved
     3  .debug_abbrev.dwo  DW_SECT_ABBREV  .debug_abbrev.dwo   DW_SECT_ABBREV
     4  .debug_line.dwo    DW_SECT_LINE    .debug_line.dwo     DW_SECT_LINE
     5  .debug_loc.dwo     DW_SECT_LOC     .debug_loclists.dwo DW_SECT_LOCLISTS
     6  .debug_str_offsets.dwo             .debug_str_offsets.dwo
                           DW_SECT_STR_OFFSETS                 DW_SECT_STR_OFFSETS
     7  .debug_macinfo.dwo DW_SECT_MACINFO .debug_macro.dwo    DW_SECT_MACRO
     8  .debug_macro.dwo   DW_SECT_MACRO   .debug_rnglists.dwo DW_SECT_RNGLISTS

as: Ignore rest of line on overflow error

* read.c (read_a_source_file): Ignore rest of line on overflow
error.

MSP430: sim: Increase main memory region size

The area between 0xFF00 and 0xFFC0 is unallocated in the simulator
memory map, so extend the main memory region up to 0xFFC0 to allow the
simulator to make use of the extra 192 bytes of space.

sim/msp430/ChangeLog:

* msp430-sim.c (sim_open): Increase the size of the main memory region
to 0xFAC0.

Automatic date update in version.in

gdb: move regcache::regcaches to regcache.c

I don't really understand why `regcache_thread_ptid_changed` is a static
method of `struct regcache` instead of being a static free function in
regcache.c.  And I don't understand why `current_regcache` is a static
member of `struct regcache` instead of being a static global in
regcache.c.  It's not wrong per-se, but there's no other place where we
do it like this in GDB (as far as I remember) and it just exposes things
unnecessarily in the .h.

Move them to be just static in regcache.c.  As a result,
registers_changed_ptid doesn't need to be friend of the regcache class
anymore.

Removing the include of forward_list in regcache.h showed that we were
missing an include for it in dwarf2/index-write.c, record-btrace.c and
sparc64-tdep.c.

gdb/ChangeLog:

* regcache.h (class regcache): Remove friend
registers_changed_ptid.
<regcache_thread_ptid_changed>: Remove.
<regcaches>: Remove.
* regcache.c (regcache::regcaches): Rename to...
(regcaches): ... this.  Make static.
(get_thread_arch_aspace_regcache): Update.
(regcache::regcache_thread_ptid_changed): Rename to...
(regcache_thread_ptid_changed): ... this.  Update.
(class regcache_access): Remove.
(regcaches_test): Update.
(_initialize_regcache): Update.
* sparc64-tdep.c, dwarf2/index-write.c, record-btrace.c: Include
<forward_list>.

Change-Id: Iabc25759848010cfbb7ee7e27f60eaca17d61c12

gdb: rename regcache::current_regcache to regcache::regcaches

The name `current_regcache` for the list of currently-existing regcaches
sounds wrong.  The name is singular, but it holds multiple regcaches, so
it could at least be `current_regcaches`.

But in other places in GDB, "current" usually means "the object we are
working with right now".  For example, we swap the "current thread" when
we want to operate on a given thread.  This is not the case here, this
variable just holds all regcaches that exist at any given time, not "the
regcache we are working with right now".

So, I think calling it `regcaches` is better.  I also considered
`regcache_list`, but a subsequent patch will make it a map and not a
list, so it would sound wrong again.  `regcaches` sounds right for any
collection of regcache, whatever the type.

Rename a few other things that were related to this `current_regcache`
field.  Note that there is a `get_current_regcache` function, which
returns the regcache of the current thread.  That one is fine, because
it returns the regcache for the current thread.

gdb/ChangeLog:

* regcache.h (class regcache) <current_regcache>: Rename to...
<regcaches>: ... this.  Move doc here.
* regcache.c (regcache::current_regcache) Rename to...
(regcache::regcaches): ... this.  Move doc to header.
(get_thread_arch_aspace_regcache): Update.
(regcache::regcache_thread_ptid_changed): Update.
(registers_changed_ptid): Update.
(class regcache_access) <current_regcache_size>: Rename to...
<regcaches_size>: ... this.
(current_regcache_test): Rename to...
(regcaches_test): ... this.
(_initialize_regcache): Update.

Change-Id: I87de67154f5fe17a1f6aee7c4f2036647ee27b99

gas: Fix internal error on long local labels

Prior to this commit, on an input such as "88888888888:", GAS hits a
signed integer overflow and likely an assertion failure. I see:

$ echo "88888888888:" | bin/aarch64-none-elf-as
{standard input}: Assembler messages:
{standard input}:1: Internal error in fb_label_name at ../gas/symbols.c:2049.
Please report this bug.

To fix this issue, I've taken two steps:

1. Change the type used for processing local labels in
   read_a_source_file() from int to long, to allow representing more
   local labels, and also since all uses of this variable (temp) are
   actually of type long.

2. Detect if we would overflow and bail out with an error message
   instead of actually overflowing and hitting the assertion in
   fb_label_name().

gas/ChangeLog:

2020-08-06  Alex Coplan  <alex.coplan@arm.com>

* read.c (read_a_source_file): Use long for local labels, detect
overflow and raise an error for overly-long labels.
* testsuite/gas/all/gas.exp: Add local-label-overflow test.
* testsuite/gas/all/local-label-overflow.d: New test.
* testsuite/gas/all/local-label-overflow.l: Error output.
* testsuite/gas/all/local-label-overflow.s: Input.

amd64_analyze_prologue: fix incorrect comment

The width of the instruction didn't match the size of its operands.

2020-06-23  Victor Collod  <vcollod@nvidia.com>

* amd64-tdep.c (amd64_analyze_prologue): Fix incorrect comment.

Change-Id: I104ebfe0b3c24bd6a8d0f0c5a791b9676a930a54

bpf: relocation fixes for eBPF ELF backend

The eBPF ELF backend was not properly recording relocation addends
during installation, nor reading and applying them when performing
the final relocation. This lead to various issues with incorrect
relocations.

These issues are fixed with a new howto special function to install
the relocations, and updates to bpf_elf_relocate_section to read and
use the addends as recorded in the input_bfd.

bfd/ChangeLog

2020-08-05  David Faust  <david.faust@oracle.com>

* elf64-bpf.c (bpf_elf_generic_reloc): New function.
(bpf_elf_howto_table): Use it here.
(bpf_elf_relocate_section): Use addends recorded in input_bfd for
instruction and data relocations.

ld/ChangeLog

2020-08-05  David Faust  <david.faust@oracle.com>

* testsuite/ld-bpf/call-2.s: New file.
* testsuite/ld-bpf/call-2.d: Likewise.
* testsuite/ld-bpf/reloc-data-be.d: Likewise.
* testsuite/ld-bpf/reloc-data-le.d: Likewise.
* testsuite/ld-bpf/reloc-data.s: Likewise.
* testsuite/ld-bpf/reloc-insn-external-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn-external-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn-external.s: Likewise.
* testsuite/ld-bpf/reloc-insn32-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn32-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn32.s: Likewise.
* testsuite/ld-bpf/reloc-insn64-be.d: Likewise.
* testsuite/ld-bpf/reloc-insn64-le.d: Likewise.
* testsuite/ld-bpf/reloc-insn64.s: Likewise.

MSP430: ld: Update output section tail when shuffling ".either" sections

The MSP430 linker shuffles input sections with names beginning with
".either" between the upper and lower memory regions, to try to avoid
one region overflowing when there is space in the other region.

However, when an ".either" input section attached to the tail of an
output section was moved to a different output section in the other
region, that tail wasn't being updated to the new section at the end
of the original output section.

This caused a bug where a shuffled section could end up in the
middle of another section in the output executable, resulting in
corrupted code or data.

When changing the output section of an input section attached to the
tail of its output section, that tail is now updated to point to
the new input section at the end of the section list.

ld/ChangeLog:

2020-08-06  Jozef Lawrynowicz  <jozef.l@mittosystems.com>

* emultempl/msp430.em (change_output_section): Update the tail
of the output section statement list when moving the original
tail to a different output section.
(eval_upper_either_sections): Don't move sections from the upper
region to the lower region unless the upper region is
overflowing.

Don't output null pathname in core_target::build_file_mappings warning

While looking into the regressions reported by Luis Machado, I noticed
that null pathnames were being output in the warnings.  E.g.

warning: Can't open file (null) during file-backed mapping note processing

I've changed the warning to output the pathname found in the note,
like this:

warning: Can't open file /var/lib/docker/aufs/diff/d07c...e21/lib/x86_64-linux-gnu/libc-2.27.so during file-backed mapping note processing

(I've shortened one of the path elements above.)

gdb/ChangeLog:

* corelow.c (core_target::build_file_mappings): Don't output
null pathname in warning.

Automatic date update in version.in