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

gdb/testsuite: link some dwarf2 tests with nopie

I noticed some gdb.dwarf2 tests not running on my machine because of
this:

    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-single-line-discriminators.exp ...
    gdb compile failed, /usr/bin/ld: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-single-line-discriminators/dw2-single-line-discriminators0.o: relocation R_X86_64_32S against
     symbol `x' can not be used when making a PIE object; recompile with -fPIE
    collect2: error: ld returned 1 exit status

We get this when the target toolchain produces position-independent
executables by default.  These tests are built from some assembly which
produces some relocations incompatible with position-independent
executables.

Add `nopie` to the compilation flags of these tests to force the
toolchain to produce non-position-independent executables.  With this,
the changed tests run successfully on my machine.

gdb/ChangeLog:

* gdb.dwarf2/clztest.exp, gdb.dwarf2/dw2-common-block.exp,
gdb.dwarf2/dw2-dup-frame.exp, gdb.dwarf2/dw2-reg-undefined.exp,
gdb.dwarf2/dw2-single-line-discriminators.exp,
dw2-undefined-ret-addr.exp: Pass nopie to compilation options.

Change-Id: Ie06c946f8e56a6030be247d1c57f416fa8b67e4c

Fix variant part regressions with older Rust compiler

Older Rust compilers used special field names, rather than DWARF
features, to express the variant parts of Rust enums.  This is handled
in gdb through a quirk recognizer that rewrites the types.

Tom de Vries pointed out in PR rust/26197 that the variant part
rewrite regressed this code.  This patch fixes the problems:

* Univariant enums were not handled properly.  Now we simply call
  alloc_rust_variant for these as well.

* There was an off-by-one error in the handling of ordinary enums.

* Ordinary enums should have the size of their member types reset to
  match the size of the enclosing enum.  (It's not clear to me if this
  is truly necessary, but it placates a test, and this is just legacy
  handling in any case.)

Tested with Rust 1.12.0, 1.14.0, 1.19.0, 1.36.0, and 1.45.0 on x86-64
Fedora 32.  There were some unrelated failures with 1.14.0 and 1.19,0;
but considering that these are fairly old releases, I don't plan to
look into them unless someone complains.

Note that this patch will not fix all the issues in the PR.  In that
PR, Tom is using a somewhat unusual build of Rust -- in particular it
uses an older (pre-DWARF variant part) LLVM with a newer Rust.  I
believe this compiler doesn't correctly implement the old-style name
fallback; the details are in the bug.

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

PR rust/26197:
* dwarf2/read.c (alloc_rust_variant): Handle univariant case.
(quirk_rust_enum): Call alloc_rust_variant for univariant case.
Fix off-by-one and type size errors in ordinary case.

MSP430: sim: Fix incorrect simulation of unsigned widening multiply

Operand sizes used for simulation of MSP430 hardware multiply
operations are not aligned with the sizes used on the target, resulting
in the simulator storing signed operands with too much precision.

Additionally, simulation of unsigned multiplication is missing explicit
casts to prevent any implicit sign extension.

gcc.c-torture/execute/pr91450-1.c uses unsigned widening multiplication
of 32-bit operands -4 and 2, to produce a 64-bit result:
0xffff fffc * 0x2 = 0x1 ffff fff8

If -4 is stored in 64-bit precision, then the multiplication is
essentially signed and the result is -8 in 64-bit precision
(0xffff ffff ffff fffc), which is not correct.

sim/msp430/ChangeLog:

* msp430-sim.c (put_op): For unsigned multiplication, explicitly cast
operands to the unsigned type before multiplying.
* msp430-sim.h (struct msp430_cpu_state): Fix types used to store hwmult
operands.

sim/testsuite/sim/msp430/ChangeLog:

* mpyull_hwmult.s: New test.

[gdb] Fix prop->const_val uses in gdbtypes.c

After commit 66d6346b25 "gdb: remove TYPE_DYN_PROP_ADDR", I run into:
...
FAIL: gdb.fortran/class-allocatable-array.exp: print this%_data%b
...
(and 185 more FAILs, all for fortran test-cases).

The commit replaces "!x" by "x != 0".

Fix this by using "x == 0" instead.

Build and tested on x86_64-linux.

gdb/ChangeLog:

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

* gdbtypes.c (type_not_allocated, type_not_associated): Use
"prop->const_val () == 0" instead of "prop->const_val () != 0".

Revert "PR26337, Malloc size error in objdump"

This reverts commit 0b97e818464a42305c8243a980a5c13967554fd9.

PR26337, Malloc size error in objdump

A malloc failure triggered by a fuzzed object file isn't a real
problem unless objdump doesn't exit cleanly after the failure, which
it does.  However we have bfd_malloc_and_get_section to sanity check
size of uncompressed sections before allocating memory.  Use it.

PR 26337
* objdump.c (load_specific_debug_section): Don't malloc space for
section contents, use bfd_malloc_and_get_section.

Automatic date update in version.in

Z8k: fix sout/soudb opcodes with direct address

Problem found by Tadashi G. Takaoka.

2020-08-04  Christian Groessler  <chris@groessler.org>
     Tadashi G. Takaoka <tadashi.g.takaoka@gmail.com>

 * z8kgen.c (opt): Fix "sout imm16,rs" and "soutb imm16,rbs"
 opcodes (special "out" to absolute address).
 * z8k-opc.h: Regenerate.

2020-08-04  Christian Groessler  <chris@groessler.org>

 * gas/testsuite/gas/z8k/inout.d: Adapt to correct encoding of
 "sout/soutb #imm,reg"

gdb: use bool in frame code

Change instances of int variables and return values used as boolean
values to use the bool type.

Shorten the comments of a few functions, because I think they go a bit
too much in implementation details, which appear out of date anyway.

Make other misc changes to the functions that are already being changed,
such as using nullptr instead of NULL, dropping `struct` keywords and
declaring variables when first used.

gdb/ChangeLog:

* frame.h (frame_id_p): Return bool.
(frame_id_artificial_p): Return bool.
(frame_id_eq): Return bool.
(has_stack_frames): Return bool.
(get_selected_frame): Fix typo in comment.
(get_frame_pc_if_available): Return bool.
(get_frame_address_in_block_if_available): Return bool.
(get_frame_func_if_available): Return bool.
(read_frame_register_unsigned): Return bool.
(get_frame_register_bytes): Return bool.
(safe_frame_unwind_memory): Return bool.
(deprecated_frame_register_read): Return bool.
(frame_unwinder_is): Return bool.
* frame.c (struct frame_info) <prev_arch::p>: Change type to
bool.
<this_id::p>: Likewise.
<prev_p>: Likewise.
(frame_stash_add): Return bool.
(get_frame_id): Use bool.
(frame_id_build_special) Use bool.
(frame_id_build_unavailable_stack): Use bool.
(frame_id_build): Use bool.
(frame_id_p): Return bool, use true/false instead of 1/0.
(frame_id_artificial_p): Likewise.
(frame_id_eq): Likewise.
(frame_id_inner): Likewise.
(get_frame_func_if_available): Likewise.
(read_frame_register_unsigned): Likewise.
(deprecated_frame_register_read): Likewise.
(get_frame_register_bytes): Likewise.
(has_stack_frames): Likewise.
(inside_main_func): Likewise.
(inside_entry_func): Likewise.
(get_frame_pc_if_available): Likewise.
(get_frame_address_in_block_if_available): Likewise.
(frame_unwinder_is): Likewise.
(safe_frame_unwind_memory): Likewise.
(frame_unwind_arch): Likewise.

Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a

gdb: change frame_info::prev_func::p type to cached_copy_status

One might think that variable `frame_info::prev_func::p` is a simple
true/false value, but that's not the case, it can also have the value -1
to mean "unavaiable".  Change it to use the `cached_copy_status` enum,
which seems designed exactly for this purpose.

Rename to `status` to be consistent with `prev_pc::status` (and be cause
`p` means `predicate`, which implies boolean, which this is not).

gdb/ChangeLog:

* frame.c (frame_info) <prev_func> <p>: Rename to status, change
type to cached_copy_status.
(fprintf_frame): Adjust.
(get_frame_func_if_available): Adjust.
(frame_cleanup_after_sniffer): Adjust.

Change-Id: I50c6ebef6c0acb076e25c741f7f417bfd101d953

Update email address in MAINTAINERS

gdb/ChangeLog:

* MAINTAINERS (Write After Approval): Update email address.

gdb: remove TYPE_DYN_PROP_ADDR

Remove TYPE_DYN_PROP_ADDR, replacing its uses with calling
dynamic_prop::const_val directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_ADDR): Remove, replace uses with
dynamic_prop::const_val.

Change-Id: Ie99b9cd9a0627488c1c69a75e57f020d34e392af

gdb: remove TYPE_DYN_PROP_KIND

Replace uses with calling the dynamic_prop::kind method directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_KIND): Remove, replace uses with
dynamic_prop::kind.

Change-Id: I78a3e2890f0b3e3950e9a19ad657b976cbb9610b

gdb: remove TYPE_DYN_PROP_BATON

This macro is now unused.

gdb/ChangeLog:

* gdbtypes.h (TYPE_DYN_PROP_BATON): Remove.

Change-Id: I6daead794f7ecb516cc59f9e05262c894515fad3

sim: generated files for the eBPF simulator

This patch adds the CGEN generated files for the eBPF simulator.

sim/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>
    David Faust <david.faust@oracle.com>

* bpf/arch.c: Likewise.
* bpf/arch.h: Likewise.
* bpf/cpu.c: Likewise.
* bpf/cpu.h: Likewise.
* bpf/cpuall.h: Likewise.
* bpf/decode-be.c: Likewise.
* bpf/decode-be.h: Likewise.
* bpf/decode-le.c: Likewise.
* bpf/decode-le.h: Likewise.
* bpf/defs-be.h: Likewise.
* bpf/defs-le.h: Likewise.
* bpf/sem-be.c: Likewise.
* bpf/sem-le.c: Likewise.

sim: eBPF simulator

This patch introduces the basics of an instruction-simulator for eBPF.
The simulator is based on CGEN.

gdb/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure.tgt: Set gdb_sim for bpf-*-* targets.

sim/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>
    David Faust <david.faust@oracle.com>

* configure.tgt (sim_arch): Add entry for bpf-*-*.
* configure: Regenerate.
* MAINTAINERS: Add maintainer for the BPF simulator.
* bpf/Makefile.in: New file.
* bpf/bpf-helpers.c: Likewise.
* bpf/bpf-helpers.def: Likewise.
* bpf/bpf-helpers.h: Likewise.
* bpf/bpf-sim.h: Likewise.
* bpf/bpf.c: Likewise.
* bpf/config.in: Likewise.
* bpf/configure.ac: Likewise.
* bpf/decode.h: Likewise.
* bpf/eng.h: Likewise.
* bpf/mloop.in: Likewise.
* bpf/sim-if.c: Likewise.
* bpf/sim-main.h: Likewise.
* bpf/traps.c: Likewise.
* bpf/configure: Generate.
* bpf/aclocal.m4: Likewise.

sim/testsuite/ChangeLog:

2020-08-04  David Faust  <david.faust@oracle.com>
    Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure: Regenerate.
* sim/bpf/allinsn.exp: New file.
* sim/bpf/alu.s: Likewise.
* sim/bpf/alu32.s: Likewise.
* sim/bpf/endbe.s: Likewise.
* sim/bpf/endle.s: Likewise.
* sim/bpf/jmp.s: Likewise.
* sim/bpf/jmp32.s: Likewise.
* sim/bpf/ldabs.s: Likewise.
* sim/bpf/mem.s: Likewise.
* sim/bpf/mov.s: Likewise.
* sim/bpf/testutils.inc: Likewise.
* sim/bpf/xadd.s: Likewise.

gdb: support for eBPF

This patch adds basic support for the eBPF target: tdep and build
machinery.  The accompanying simulator is introduced in subsequent
patches.

gdb/ChangeLog:

2020-08-04  Weimin Pan <weimin.pan@oracle.com>
    Jose E. Marchesi  <jose.marchesi@oracle.com>

* configure.tgt: Add entry for bpf-*-*.
* Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o
(ALLDEPFILES): Add bpf-tdep.c.
* bpf-tdep.c: New file.
* MAINTAINERS: Add bpf target and maintainer.

gdb/doc/ChangeLog:

2020-08-04  Jose E. Marchesi  <jose.marchesi@oracle.com>

* gdb.texinfo (Contributors): Add information for the eBPF
support.
(BPF): New section.

gdb/testsuite: Use 'array unset' instead of just 'unset'

In the check-test-names.exp library 'unset' was being used to unset an
array variable.  Though this seems to work fine on tcl 8.6, it was
discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this
doesn't work and 'array unset' should be used instead.

Using 'array unset' should work fine for newer and older versions of
tcl (since 8.3, releases ~2000).

gdb/testsuite/ChangeLog:

* lib/check-test-names.exp (do_reset_vars): Use 'array unset' to
unset the array variable.

gas/NEWS: Mention {disp16} pseudo prefix

* NEWS: Mention {disp16} pseudo prefix.

gas: Revert an accidental change in x86-64-pseudos.d

Revert an accidental change in

commit 41eb8e88859b297f59f4d093aab9306d4b7057d9
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Jul 30 16:13:02 2020 -0700

    x86: Add {disp16} pseudo prefix

@@ -304,7 +308,7 @@ Disassembly of section .text:
  +[a-f0-9]+:  40 d3 e0                rex shl %cl,%eax
  +[a-f0-9]+:  40 a0 01 00 00 00 00 00 00 00    rex movabs 0x1,%al
  +[a-f0-9]+:  40 38 ca                rex cmp %cl,%dl
- +[a-f0-9]+:  40 b3 01                rex mov \$(0x)?1,%bl
+ +[a-f0-9]+:  40 b3 01                rex mov \$(0x)1,%bl
  +[a-f0-9]+:  f2 40 0f 38 f0 c1       rex crc32 %cl,%eax
  +[a-f0-9]+:  40 89 c3                rex mov %eax,%ebx
  +[a-f0-9]+:  41 89 c6                mov    %eax,%r14d

PR gas/26305
* testsuite/gas/i386/x86-64-pseudos.d: Revert an accidental
change.

gas: Use udata for DW_AT_high_pc when emitting DWARF4

For DWARF4 DW_AT_high_pc can be expressed as constant offset from
DW_AT_low_pc which saves a relocation. Use DW_FORM_udate (uleb128)
to keep the constant value as small as possible.

gas/ChangeLog:

       * dwarf2dbg.c (out_debug_abbrev): When DWARF2_VERSION >= 4, use
       DW_FORM_udata for DW_AT_high_pc.
       (out_debug_info): Use emit_leb128_expr for DW_AT_high_pc, when
       DWARF2_VERSION >= 4.
       * read.c (emit_leb128_exp): No longer static.
       * read.h (emit_leb128_exp): Define.

gas: Make sure .debug_line file table contains a zero filename and dir

For DWARF5 the zero file list entry in the .debug_line table represents
the compile unit main file. It can be set with .file 0 when -gdwarf-5
is given. But since this directive is illegal for older versions, this
is almost never set. To make sure it is always set (so DW_AT_name of
the compile unit can be set) use file (and dir) 1 if that is defined
(otherwise fall back to pwd, to match DW_AT_comp_dir).

gas/ChangeLog:

* gas/dwarf2dbg.c (out_dir_and_file_list): For DWARF5 emit at
least one directory if there is at least one file. Use dirs[1]
if dirs[0] is not set, or if there is no dirs[1] the current
working directory. Use files[1] filename, when files[0] filename
isn't set.

gas: Fix .debug_info CU header for --gdwarf-5

DWARF5 CU headers have a new unit type field and move the abbrev offset
to the end of the header.

gas/ChangeLog:

* dwarf2dbg.c (out_debug_info): Emit unit type and abbrev offset
for DWARF5.
* gas/testsuite/gas/elf/dwarf-4-cu.d: New file.
* gas/testsuite/gas/elf/dwarf-4-cu.s: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.d: Likewise.
* gas/testsuite/gas/elf/dwarf-5-cu.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-4-cu and dwarf-5-cu.

gas: Fix as.texi typo infortmation

gas/ChangeLog:

* doc/as.texi (--gdwarf-[345]): Fix typo.

[gdb/symtab] Handle invalid partial DIE reference

When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix
gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE
  0x1b7 in cache [from module amd64-entry-value-paramref]^M

A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
...
because of invalid dwarf.

In contrast, when using -readnow, we have:
...
(gdb) file -readnow amd64-entry-value-paramref
Reading symbols from amd64-entry-value-paramref...
Expanding full symbols from amd64-entry-value-paramref...
Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \
  [in module amd64-entry-value-paramref]
(gdb)
...

Change the internal error into a Dwarf Error, such that we have:
...
(gdb) file amd64-entry-value-paramref^M
Reading symbols from amd64-entry-value-paramref...^M
Dwarf Error: Cannot not find DIE at 0x1b7 \
  [from module amd64-entry-value-paramref]^M
^M
(No debugging symbols found in amd64-entry-value-paramref)^M
(gdb)
...

Build and tested on x86_64-linux.

gdb/ChangeLog:

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

PR symtab/23270
* dwarf2/read.c (find_partial_die): Change internal error into Dwarf
Error.

Automatic date update in version.in

Update FreeBSD system calls for 13.0-CURRENT.

This matches the current set of system calls in the FreeBSD head
development branch as of r363367.  Some of these system calls
were also included in 12.1 release.

gdb/ChangeLog:

* syscalls/freebsd.xml: Regenerate.

Fix script name in usage and generated year range.

gdb/ChangeLog:

* syscalls/update-freebsd.sh: Fix usage and year range.

MSP430: Remove unused -md GAS option

The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically by
looking for the presence of certain symbols in the input file.

gas/ChangeLog:

* config/tc-msp430.c (OPTION_MOVE_DATA): Remove.
(md_parse_option): Remove case for OPTION_MOVE_DATA.
(md_longopts): Remove "md" entry.
(md_show_usage): Likewise.

[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user range

When reading an exec with a .debug_line section containing a vendor-specific
extended opcode, we get:
...
$ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
During symbol reading: mangled .debug_line section
...
and reading of the .debug_line section is abandoned.

The vendor-specific extended opcode should be ignored, as specified in the
DWARF standard (7.1 Vendor Extensibility).  [ FWIW, vendor-specific
standard opcodes are already ignored. ]

Fix this by ignoring all vendor-specific extended opcodes.

Build and tested on x86_64-linux.

gdb/ChangeLog:

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

PR symtab/26333
* dwarf2/read.c (dwarf_decode_lines_1): Ignore
DW_LNE_lo_user/DW_LNE_hi_user range.

gdb/testsuite/ChangeLog:

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

PR symtab/26333
* lib/dwarf.exp (DW_LNE_user): New proc.
* gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.

asan: alpha-vms: buffer overflow in vms_traverse_index

* vms-lib.c (vms_traverse_index): Sanity check size remaining
before accessing vms_idx or vms_elfidx.

PR26330, Malloc size error in objdump

PR 26330
* elf.c (_bfd_elf_get_symtab_upper_bound): Sanity check symbol table
size against file size.  Correct LONG_MAX limit check.
(_bfd_elf_get_dynamic_symtab_upper_bound): Likewise.
(_bfd_elf_get_reloc_upper_bound): Don't check file size if writing.
(_bfd_elf_get_dynamic_reloc_upper_bound): Likewise.
* elf64-x86-64-.c (elf_x86_64_get_synthetic_symtab): Use
bfd_malloc_and_get_section.

Use xmalloc rather than malloc

As far as I can tell, the following comment is false nowadays.
/* Calls to m-alloc get turned by sed into xm-alloc.  */

Remove it, and call xmalloc.

* ldlex.l (yy_create_string_buffer): Use xmalloc rather than malloc.
* lexsup.c (parse_args): Likewise.

PR26328, Compilation warning when building ld v2.35 with MinGW

PR 26328
* configure.ac: AC_CHECK_DECLS asprintf.
* configure: Regenerate.
* config.in: Regenerate.

Tidy objdump_symstuff and objdump_dynsymstuff

* testsuite/ld-elfvers/vers.exp (objdump_symstuff): Remove unused
variable.  Init list_a and list_b to empty.
(objdump_dynsymstuff): Likewise, and remove undefined list_a
handling.
* testsuite/ld-elfweak/elfweak.exp (objdump_symstuff): Similarly.
(objdump_dynsymstuff): Similarly.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilib

There are compilation warnings / errors when compiling coremaker2.c
for the gdb.base/corefile2.exp tests.  Here's the command to use
on x86_64 linux:

make check RUNTESTFLAGS="--target_board unix/-m32" \
           TESTS="gdb.base/corefile2.exp"

These are the warnings / errors - I've shortened the paths somewhat:

gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main':
gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  106 |   addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1);
      |           ^
gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  108 |   if (addr <= (unsigned long long) buf_ro
      |               ^
gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  109 |       || addr >= (unsigned long long) buf_ro + sizeof (buf_ro))
      |                  ^
gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  115 |   mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ,
      |                   ^
gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  130 |   addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1);
      |           ^
gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  132 |   if (addr <= (unsigned long long) buf_rw
      |               ^
gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  133 |       || addr >= (unsigned long long) buf_rw + sizeof (buf_rw))
      |                  ^
gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  139 |   mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ,
      |                   ^

These were fixed by changing unsigned long long to uintptr_t.

Tested on either rawhide or Fedora 32 with architectures: x86_64,
x86_64/-m32, aarch64, s390x, and ppc64le.

gdb/testsuite/ChangeLog:

* gdb.base/coremaker2.c: Change all uses of 'unsigned long long'
to 'uintptr_t'
(inttypes.h): Include.

Fix gdb.base/corefile2.exp test case for ppc64le

It turns out that the recently added gdb.base/corefile2.exp test won't
run on ppc64le linux.  The test case fails the internal checks which
ensure that a mmap'd region can be placed within the statically
allocated regions buf_rw[] and buf_ro[].

ppc64le linux apparently has 64k pages, which is much larger than
the 24k regions originally allocated for buf_rw[] and buf_ro[].

This patch increases the size of each region to 256 KiB.

Tested on either rawhide or Fedora 32 for these architectures: x86_64,
x86_64/-m32, ppc64le, aarch64, and s390x.

gdb/testsuite/ChangeLog:

* gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB.
(C5_24k): Delete.
(C5_8k, C5_64k, C5_256k): New macros.
(buf_ro): Allocate 256 KiB of initialized data.

ld: Add -fno-lto to linker tests

LTO can be used to build binutils with

$ CC="gcc -flto -ffat-lto-objects -Wl,--as-needed" CXX="g++ -flto -ffat-lto-objects -Wl,--as-needed" .../configure

But not all linker tests are compatible with LTO.  Pass -fno-lto to CC
to disable LTO on linker tests by default.  -flto is passed explicitly
to CC in linker LTO tests.

* testsuite/ld-elf/indirect.exp: Append -fno-lto to CC.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-plugin/lto.exp (no_lto): New.
Add $no_lto to build pr15146c.so.
* testsuite/lib/ld-lib.exp (at_least_gcc_version): Filter out
-Wl,xxx options.
(check_gcc_plugin_enabled): Likewise.
(run_ld_link_exec_tests): Prepend -fno-lto to $cflags.
(run_cc_link_tests): Likewise.

PR26314, Linking LTO objects with symbols from static and shared libraries

gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,.

All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so
not being found needed when loading the IR objects.  That's problem
number one:  We exclude IR references when deciding a shared library
is needed.  See PR15146.  Thus none of the libbfd.so symbols are
loaded before libiberty.a is scanned, and libbfd.so contains copies of
libiberty.a functions.  We ought to be using the libbfd.so copies
rather than extracting them from the archive (an object is extracted
even to satisfy IR symbols).  After lto recompilation, libbfd.so is of
course found to be needed and loaded.  But that causes more problems.
The lto recompilation didn't see symbol references from libbfd.so and
variables like _xexit_cleanup are made local in the recompiled
objects.  Oops, two copies of them.  Finally, those silly undefined
symbols in the lto output debug files, combined with definitions in
both libbfd.so and IR objects result in IR symbols being made
dynamic.

The main fix here is to revert the PR15146 change to
elf_link_add_object_symbols.

PR 26314
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow
IR symbols to become dynamic.
(elf_link_add_object_symbols): Don't exclude IR symbols when
deciding whether an as-needed shared library is needed.

ARC: Fix ld/pr24511 test

With this patch, ld/pr24511 test passes for ARC.

At first glance, the test was failing because the order of
"__init_array_start" and "__fini_array_start" weak symbols were
reversed:

$ nm -n dump.out

      expected output          |          real output
00002104 D __init_array_start  |  00002104 D __fini_array_start
0000210c D __fini_array_start  |  00002104 D __init_array_start

The order of the symbols are different as a side effect of both
symbols being mapped to the _same_ address (0x2104).  Looking
further into the mapping logs [1] revealed that the linker
script must consider all instances of ".init_array" (in other
words ".init_array.*") inside its relevant section. Same logic
holds for ".fini_array".

Therefore, adding "KEEP (*(SORT(.init_array.*)))" to the linker
script, along with the one for ".finit_array.*", resolved the
problem.  While at it, I took the liberty of refactoring the
script a little bit and made those pieces of script macros.

[1] Linker's mapping for the relevant part of the test
---------------------------------------------------------------
.init_array     0x2104        0x0
                0x2104        PROVIDE (__init_array_start = .)
 *(.init_array)
                [!provide]    PROVIDE (__init_array_end = .)

.fini_array     0x2104        0x0
                0x2104        PROVIDE (__fini_array_start = .)
 *(.fini_array)
                [!provide]    PROVIDE (__fini_array_end = .)

.data           0x2104        0x0
 *(.data .data.* .gnu.linkonce.d.*)
 .data          0x2104        0x0 pr24511.o

.init_array.01000
                0x2104        0x8
 .init_array.01000
                0x2104        0x8 pr24511.o

.fini_array.01000
                0x210c        0x8
 .fini_array.01000
                0x210c        0x8 pr24511.o
---------------------------------------------------------------

ld:
* scripttempl/elfarc.sc (.init_array): Keep ".init_array.*".
  (.fini_array): Keep ".fini_array.*".

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

Automatic date update in version.in

x86: Add {disp16} pseudo prefix

Use Prefix_XXX for pseudo prefixes.  Add {disp16} pseudo prefix and
replace {disp32} pseudo prefix with {disp16} in 16-bit mode test.
Check invalid {disp16}/{disp32} pseudo prefixes.

gas/

PR gas/26305
* config/tc-i386.c (_i386_insn::disp_encoding): Add
disp_encoding_16bit.
(parse_insn): Check Prefix_XXX for pseudo prefixes.  Handle
{disp16}.
(build_modrm_byte): Handle {disp16}.
(i386_index_check): Check invalid {disp16} and {disp32} pseudo
prefixes.
* doc/c-i386.texi: Update {disp32} documentation and document
{disp16}.
* testsuite/gas/i386/i386.exp: Run x86-64-inval-pseudo.
* testsuite/gas/i386/inval-pseudo.s: Add {disp32}/{disp16}
tests.
* testsuite/gas/i386/pseudos.s: Add {disp8}/{disp32} vmovaps
tests with 128-byte displacement.  Add {disp16} tests.
* testsuite/gas/i386/x86-64-pseudos.s: Add {disp8}/{disp32}
vmovaps test.  Add (%r13)/(%r13d) tests.
* testsuite/gas/i386/x86-64-inval-pseudo.l: New file.
* testsuite/gas/i386/x86-64-inval-pseudo.s: Likewise.
* testsuite/gas/i386/inval-pseudo.l: Updated.
* testsuite/gas/i386/pseudos.d: Likewise.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.

opcodes/

PR gas/26305
* i386-opc.h (Prefix_Disp8): New.
(Prefix_Disp16): Likewise.
(Prefix_Disp32): Likewise.
(Prefix_Load): Likewise.
(Prefix_Store): Likewise.
(Prefix_VEX): Likewise.
(Prefix_VEX3): Likewise.
(Prefix_EVEX): Likewise.
(Prefix_REX): Likewise.
(Prefix_NoOptimize): Likewise.
* i386-opc.tbl: Use Prefix_XXX on pseudo prefixes.  Add {disp16}.
* i386-tbl.h: Regenerated.

gdb: handle non-const property types in ada_modulus (PR ada/26318)

PR 26318 shows that running `maint print symbols` on an Ada binary,
compiled with an Ada distribution that includes debug info for the
standard library, triggers this assertion:

    /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.

The problem is in particular when printing type
`system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which
has a dynamic high bound (PROP_LOCLIST kind).  When printing a concrete
value of this type, this type gets resolved to a type with a constant
high bound, so ada_modulus can return this constant value.

However, when printing the dynamic range type on its own, such as with
`maint print symbols`, the high bound is still of kind PROP_LOCLIST.
When ada_modulus tries to access the property as a const value, the
assert triggers.

There's no sensible numerical value to return in this case.  Ideally,
ada_modulus would return something to the caller indicating that the
value is dynamic and therefore can't be returned as an integer.  The
callers would handle it, for example `maint print symbols` would say
that the high bound of the type is dynamic.

However, this patch implements the simpler fix of returning 0 in that
case.  It kind of restores the previous behavior of before we validated
the dynamic property kind in the getters, where we would just return
whatever random integer value was in `const_val`.  Except now it's
consistently 0.

This is what we had before we added dynamic property getters:

$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
     typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257;

and this is what we have now:

$ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1'
     typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0;

The value 107820865988257 is the `baton` field of the property's union
interpreted as an integer, so a bogus value.

gdb/ChangeLog:

PR ada/26318
* ada-lang.c (ada_modulus): Return 0 if property is not of const
kind.

Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50

gdb/breakpoint: refactor 'set_breakpoint_condition'

Apply minor refactoring to 'set_breakpoint_condition'.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Do minor refactoring.

gdb/breakpoint: set the condition exp after parsing the condition successfully

In 'set_breakpoint_condition', GDB resets the condition expressions
before parsing the condition input by the user.  This leads to the
problem of losing the condition expressions if the new condition
does not parse successfully and is thus rejected.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) start
  Temporary breakpoint 1 at 0x114e: file test.c, line 4.
  Starting program: test

  Temporary breakpoint 1, main () at test.c:4
  4         int a = 10;
  (gdb) break 5
  Breakpoint 2 at 0x555555555155: file test.c, line 5.

Now define a condition that would evaluate to false.  Next, attempt
to overwrite that with an invalid condition:

  (gdb) cond 2 a == 999
  (gdb) cond 2 gibberish
  No symbol "gibberish" in current context.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   0x0000555555555155 in main at test.c:5
          stop only if a == 999

It appears as if the bad condition is successfully rejected.  But if we
resume the program, we see that we hit the breakpoint although the condition
would evaluate to false.

  (gdb) continue
  Continuing.

  Breakpoint 2, main () at test.c:5
  5         a = a + 1; /* break-here */

Fix the problem by not resetting the condition expressions before
parsing the condition input.

Suppose the fix is applied.  A similar problem could occur if the
condition is valid, but has "junk" at the end.  In this case, parsing
succeeds, but an error is raised immediately after.  It is too late,
though; the condition expression is already updated.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) start
  Temporary breakpoint 1 at 0x114e: file test.c, line 4.
  Starting program: test

  Temporary breakpoint 1, main () at test.c:4
  4         int a = 10;
  (gdb) break 5
  Breakpoint 2 at 0x555555555155: file test.c, line 5.
  (gdb) cond 2 a == 999
  (gdb) cond 2 a == 10 if
  Junk at end of expression
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       breakpoint     keep y   0x0000555555555155 in main at test.c:5
          stop only if a == 999
  (gdb) c
  Continuing.

  Breakpoint 2, main () at test.c:5
  5         a = a + 1; /* break-here */
  (gdb)

We should not have hit the breakpoint because the condition would
evaluate to false.

Fix this problem by updating the condition expression of the breakpoint
after parsing the input successfully and checking that there is no
remaining junk.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Update the condition
expressions after checking that the input condition string parses
successfully and does not contain junk at the end.

gdb/testsuite/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/condbreak-bad.exp: Extend the test with scenarios
that attempt to overwrite an existing condition with a condition
that fails parsing and also with a condition that parses fine
but contains junk at the end.

gdb/breakpoint: do not update the condition string if parsing the condition fails

The condition of a breakpoint can be set with the 'cond' command.  If
the condition has errors that make it problematic to evaluate, it
appears like GDB rejects the condition, but updates the breakpoint's
condition string, which causes incorrect/unintuitive behavior.

For instance:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) break 5
  Breakpoint 1 at 0x1155: file test.c, line 5.
  (gdb) cond 1 gibberish
  No symbol "gibberish" in current context.

At this point, it looks like the condition was rejected.
But "info breakpoints" shows the following:

  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   0x0000000000001155 in main at test.c:5
          stop only if gibberish

Running the code gives the following behavior, where re-insertion of
the breakpoint causes failures.

  (gdb) run
  Starting program: test
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  warning: failed to reevaluate condition for breakpoint 1: No symbol "gibberish" in current context.
  [Inferior 1 (process 19084) exited normally]
  (gdb)

This broken behavior occurs because GDB updates the condition string
of the breakpoint *before* checking that it parses successfully.
When parsing fails, the update has already taken place.

Fix the problem by updating the condition string *after* parsing the
condition.  We get the following behavior when this patch is applied:

  $ gdb ./test
  Reading symbols from ./test...
  (gdb) break 5
  Breakpoint 1 at 0x1155: file test.c, line 5.
  (gdb) cond 1 gibberish
  No symbol "gibberish" in current context.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  1       breakpoint     keep y   0x0000000000001155 in main at test.c:5
  (gdb) run
  Starting program: test

  Breakpoint 1, main () at test.c:5
  5         a = a + 1; /* break-here */
  (gdb) c
  Continuing.
  [Inferior 1 (process 15574) exited normally]
  (gdb)

A side note: The problem does not occur if the condition is given
at the time of breakpoint definition, as in "break 5 if gibberish",
because the parsing of the condition fails during symtab-and-line
creation, before the breakpoint is created.

Finally, the code included the following comment:

  /* I don't know if it matters whether this is the string the user
     typed in or the decompiled expression.  */

This comment did not make sense to me because the condition string is
the user-typed input.  The patch updates this comment, too.

gdb/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (set_breakpoint_condition): Update the
condition string after parsing the new condition successfully.

gdb/testsuite/ChangeLog:
2020-07-30  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/condbreak-bad.c: New test.
* gdb.base/condbreak-bad.exp: New file.

aarch64: set sh_entsize of .plt to 0

On aarch64 the first PLT entry is 32 bytes, subsequent entries
are 16 bytes by default but can be 24 bytes with BTI or with
PAC-PLT.

sh_entsize of .plt was set to the PLT entry size, so in some
cases sh_size % sh_entsize != 0, which breaks some tools.

Note that PLT0 (and the TLSDESC stub code which is also in the
PLT) were historically not padded up to meet the sh_size
requirement, but to ensure that PLT stub code is aligned on
cache lines. Similar layout is present on other targets too
which just happens to make sh_size a multiple of sh_entsize and
it is not expected that sh_entsize of .plt is used for anything.

This patch sets sh_entsize of .plt to 0: the section does not
hold a table of fixed-size entries so other values are not
conforming in principle to the ELF spec.

bfd/ChangeLog:

PR ld/26312
* elfnn-aarch64.c (elfNN_aarch64_init_small_plt0_entry): Set sh_entsize
to 0.
(elfNN_aarch64_finish_dynamic_sections): Remove sh_entsize setting.

[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-4.8

When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I
get:
...
FAIL: gdb.fortran/info-modules.exp: info module functions: \
  check for entry 'info-types.f90', '35', \
  'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \
  check for entry 'info-types.f90', '35', \
  'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
  check for entry 'info-types.f90', '(35)?', \
  'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
  check for entry 'info-types.f90', '(35)?', \
  'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...

With gfortran 7.5.0, we have:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
    <286>   DW_AT_name        : __def_init_mod1_M1t1
    <29f>   DW_AT_name        : __vtype_mod1_M1t1
    <3de>   DW_AT_name        : __copy_mod1_M1t1
$
...
but with gfortran 4.8.5:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
$
...

Fix this by allowing these module functions and variables to be missing.

Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0.

gdb/testsuite/ChangeLog:

2020-07-30  Tom de Vries  <tdevries@suse.de>

* lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor
out of ...
(GDBInfoModuleSymbols::check_entry): ... here.
(GDBInfoModuleSymbols::check_optional_entry): New proc.
* gdb.fortran/info-modules.exp: Use check_optional_entry for entries
related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.

Strange - my previous commit to as.c to set the default dwarf level to 3 seems to have disappeared.  So here is the commit again.

Default to DWARF level 3 for the assembler.

* as.c (dwarf_level): Initialise to 3 in case this is not set on
the command line.

Unify Solaris procfs and largefile handling

GDB currently doesn't build on 32-bit Solaris:

* On Solaris 11.4/x86:

In file included from /usr/include/sys/procfs.h:26,
                 from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24:
/usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment"
 #error "Cannot use procfs in the large file compilation environment"
  ^~~~~

* On Solaris 11.3/x86 there are several more instances of this.

The interaction between procfs and large-file support historically has
been a royal mess on Solaris:

* There are two versions of the procfs interface:

** The old ioctl-based /proc, deprecated and not used any longer in
   either gdb or binutils.

** The `new' (introduced in Solaris 2.6, 1997) structured /proc.

* There are two headers one can possibly include:

** <procfs.h> which only provides the structured /proc, definining
   _STRUCTURED_PROC=1 and then including ...

** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based
   /proc, but provides structured /proc if _STRUCTURED_PROC == 1.

* procfs and the large-file environment didn't go well together:

** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit
   compilations when the large-file environment was active
   (_FILE_OFFSET_BITS == 64).

** In both Solaris 11.4 and Illumos, this restriction was lifted for
   structured /proc.

So one has to be careful always to define _STRUCTURED_PROC=1 when
testing for or using <sys/procfs.h> on Solaris.  As the errors above
show, this isn't always the case in binutils-gdb right now.

Also one may need to disable large-file support for 32-bit compilations
on Solaris.  config/largefile.m4 meant to do this by wrapping the
AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding
ACX_LARGEFILE.  Unfortunately the macro doesn't always succeed because
it neglects the _STRUCTURED_PROC part.

To make things even worse, since GCC 9 g++ predefines
_FILE_OFFSET_BITS=64 on Solaris.  So even if largefile.m4 deciced not to
enable large-file support, this has no effect, breaking the gdb build.

This patch addresses all this as follows:

* All tests for the <sys/procfs.h> header are made with
  _STRUCTURED_PROC=1, the definition going into the various config.h
  files instead of having to make them (and sometimes failing) in the
  affected sources.

* To cope with the g++ predefine of _FILE_OFFSET_BITS=64,
  -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables.  It had
  been far easier to have just

  #undef _FILE_OFFSET_BITS

  in config.h, but unfortunately such a construct in config.in is
  commented by config.status irrespective of indentation and whitespace
  if large-file support is disabled.  I found no way around this and
  putting the #undef in several global headers for bfd, binutils, ld,
  and gdb seemed way more invasive.

* Last, the applicability check in largefile.m4 was modified only to
  disable largefile support if really needed.  To do so, it checks if
  <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined.  If it
  doesn't, the disabling only happens if gdb exists in-tree and isn't
  disabled, otherwise (building binutils from a tarball), there's no
  conflict.

  What initially confused me was the check for $plugins here, which
  originally caused the disabling not to take place.  Since AC_PLUGINGS
  does enable plugin support if <dlfcn.h> exists (which it does on
  Solaris), the disabling never happened.

  I could find no explanation why the linker plugin needs large-file
  support but thought it would be enough if gld and GCC's lto-plugin
  agreed on the _FILE_OFFSET_BITS value.  Unfortunately, that's not
  enough: lto-plugin uses the simple-object interface from libiberty,
  which includes off_t arguments.  So to fully disable large-file
  support would mean also disabling it in libiberty and its users: gcc
  and libstdc++-v3.  This seems highly undesirable, so I decided to
  disable the linker plugin instead if large-file support won't work.

The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both
Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to
predefined _FILE_OFFSET_BITS=64).  Also regtested on
amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4),
x86_64-pc-linux-gnu and i686-pc-linux-gnu.

config:
* largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>:
Check for <sys/procfs.h> incompatilibity with large-file support
on Solaris.
Only disable large-file support and perhaps plugins if needed.
Set, substitute LARGEFILE_CPPFLAGS if so.

bfd:
* bfd.m4 (BFD_SYS_PROCFS_H): New macro.
(BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H.
Don't define _STRUCTURED_PROC.
(BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise.
* elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define.
* configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>.
* configure, config.in: Regenerate.
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.

binutils:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.

gas:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in, doc/Makefile.in: Regenerate.
* configure: Regenerate.

gdb:
* proc-api.c (_STRUCTURED_PROC): Don't define.
* proc-events.c: Likewise.
* proc-flags.c: Likewise.
* proc-why.c: Likewise.
* procfs.c: Likewise.

* Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* configure, config.in: Regenerate.

gdbserver:
* configure, config.in: Regenerate.

gdbsupport:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for
<sys/procfs.h>.
* Makefile.in: Regenerate.
* configure, config.in: Regenerate.

gnulib:
* configure.ac: Run ACX_LARGEFILE before gl_EARLY.
* configure: Regenerate.

gprof:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.

ld:
* Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS.
* Makefile.in: Regenerate.
* configure: Regenerate.

x86: Pass --gdwarf-3 to assembler

Pass --gdwarf-3 to assembler for

commit 4d8ee860737005517be588f4771c358593fa421c
Author: Nick Clifton <nickc@redhat.com>
Date:   Thu Jul 30 08:39:14 2020 +0100

    Prevent the generation of DWARF level 0 line number tables...

binutils/

* testsuite/binutils-all/i386/compressed-1a.d: Pass --gdwarf-3
to assembler.
* testsuite/binutils-all/i386/compressed-1b.d: Likewise.
* testsuite/binutils-all/i386/compressed-1c.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1a.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1b.d: Likewise.
* testsuite/binutils-all/x86-64/compressed-1c.d: Likewise.

gas/

* testsuite/gas/elf/dwarf2-3.d:Pass --gdwarf-3 to assembler.
* testsuite/gas/elf/dwarf2-5.d: Likewise.
* testsuite/gas/i386/dw2-compress-3a.d: Likewise.
* testsuite/gas/i386/dw2-compress-3b.d: Likewise.
* testsuite/gas/i386/dw2-compressed-3a.d: Likewise.
* testsuite/gas/i386/dw2-compressed-3b.d: Likewise.