Fixed gdb to print arrays with very high indexes

In the function f77_print_array_1, the variable 'i' which holds the
index is of datatype 'int', while bounds are of datatype LONGEST. Due to
size of int being smaller than LONGEST, the variable 'i' stores
incorrect values for high indexes (higher than max limit of int).  Due
to this issue in sources, two abnormal behaviors are seen while printing
arrays with high indexes (please check array-bounds-high.f90) For high
indexes with negative sign, gdb prints empty array even if the array has
elements.

    (gdb) p arr
    $1 = ()

For high indexes with positive sign, gdb crashes.  We have now changed
the datatype of 'i' to LONGEST which is same as datatype of bounds.

gdb/ChangeLog:

* f-valprint.c (f77_print_array_1): Changed datatype of index
variable to LONGEST from int to enable it to contain bound
values correctly.

gdb/testsuite/ChangeLog:

* gdb.fortran/array-bounds-high.exp: New file.
* gdb.fortran/array-bounds-high.f90: New file.

Change-Id: Ie2dce9380a249e634e2684b9c90f225e104369b7

Automatic date update in version.in

readelf: add missing newlines to error messages

* readelf.c (dump_relocations, dump_relocations)
(decode_arm_unwind_bytecode, process_dynamic_section)
(get_symbol_visibility, get_alpha_symbol_other): Add newline to
error message.

RISC-V/Linux/native: Determine FLEN dynamically

Fix RISC-V native Linux support to handle a 64-bit FPU (FLEN == 64) with
both RV32 and RV64 systems, which is a part of the current Linux ABI for
hard-float systems, rather than assuming that (FLEN == XLEN) in target
description determination and that (FLEN == 64) in register access.

We can do better however and not rely on any particular value of FLEN
and probe for it dynamically, by observing that the PTRACE_GETREGSET
ptrace(2) call will only accept an exact regset size, and that will
reflect FLEN.  Therefore iterate over the call in target description
determination with a geometrically increasing regset size until a match
is marked by a successful ptrace(2) call completion or we run beyond the
maximum size we can support.

Update register accessors accordingly, using FLEN determined to size the
buffer used for NT_PRSTATUS requests and then to exchange data with the
regcache.

Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG,
however NFPREG is nowhere defined.

gdb/
* riscv-linux-nat.c [!NFPREG] (NFPREG): New macro.
(supply_fpregset_regnum, fill_fpregset): Handle regset buffer
offsets according to FLEN determined.
(riscv_linux_nat_target::read_description): Determine FLEN
dynamically.
(riscv_linux_nat_target::fetch_registers): Size regset buffer
according to FLEN determined.
(riscv_linux_nat_target::store_registers): Likewise.

Fix compilation error with musl in gdb/testsuite/gdb.base/fileio.c

Musl is giving warnings about these includes in this way:
warning: #warning redirecting incorrect #include <sys/errno.h> to <errno.h>
warning: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h>

gdb/testsuite/Changelog:

* gdb.base/fileio.c: Remove #include of <sys/errno.h>.
Replace #include of <sys/fcntl.h> by <fcntl.h>.

binutils: drop redundant 'program_name' definition (-fno-common)

* coffdump.c (program_name): Drop redundant definition.
* srconv.c (program_name): Likewise
* sysdump.c (program_name): Likewise

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

ubsan: m32c: left shift of negative value

cpu/
* m32c.cpu (f-dsp-64-s16): Mask before shifting signed value.
opcodes/
* m32c-ibld.c: Regenerate.

section.c: Fix typo in comments (withe -> with)

* bfd-in2.h: Regenerated.
* section.c (SEC_ASSEMBLER_SECTION_ID): Fix a typo in comments.

ELF: Add support for unique section ID to assembler

Clang's integrated assembler supports multiple section with the same
name:

.section .text,"ax",@progbits,unique,1
nop
.section .text,"ax",@progbits,unique,2
nop

"unique,N" assigns the number, N, as the section ID, to a section.  The
valid values of the section ID are between 0 and 4294967295.  It can be
used to distinguish different sections with the same section name.

This is useful with -fno-unique-section-names -ffunction-sections.
-ffunction-sections by default generates .text.foo, .text.bar, etc.
Using the same string can save lots of space in .strtab.

This patch adds section_id to bfd_section and reuses the linker
internal bit in BFD section flags, SEC_LINKER_CREATED, for assmebler
internal use to mark valid section_id.  It also updates objdump to
compare section pointers if 2 sections comes from the same file since
2 different sections can have the same section name.

bfd/

PR gas/25380
* bfd-in2.h: Regenerated.
* ecoff.c (bfd_debug_section): Add section_id.
* section.c (bfd_section): Add section_id.
(SEC_ASSEMBLER_SECTION_ID): New.
(BFD_FAKE_SECTION): Add section_id.

binutils/

PR gas/25380
* objdump.c (sym_ok): Return FALSE if 2 sections are in the
same file with different section pointers.

gas/

PR gas/25380
* config/obj-elf.c (section_match): Removed.
(get_section): Also match SEC_ASSEMBLER_SECTION_ID and
section_id.
(obj_elf_change_section): Replace info and group_name arguments
with match_p.  Also update the section ID and flags from match_p.
(obj_elf_section): Handle "unique,N".  Update call to
obj_elf_change_section.
* config/obj-elf.h (elf_section_match): New.
(obj_elf_change_section): Updated.
* config/tc-arm.c (start_unwind_section): Update call to
obj_elf_change_section.
* config/tc-ia64.c (obj_elf_vms_common): Likewise.
* config/tc-microblaze.c (microblaze_s_data): Likewise.
(microblaze_s_sdata): Likewise.
(microblaze_s_rdata): Likewise.
(microblaze_s_bss): Likewise.
* config/tc-mips.c (s_change_section): Likewise.
* config/tc-msp430.c (msp430_profiler): Likewise.
* config/tc-rx.c (parse_rx_section): Likewise.
* config/tc-tic6x.c (tic6x_start_unwind_section): Likewise.
* doc/as.texi: Document "unique,N" in .section directive.
* testsuite/gas/elf/elf.exp: Run "unique,N" tests.
* testsuite/gas/elf/section15.d: New file.
* testsuite/gas/elf/section15.s: Likewise.
* testsuite/gas/elf/section16.s: Likewise.
* testsuite/gas/elf/section16a.d: Likewise.
* testsuite/gas/elf/section16b.d: Likewise.
* testsuite/gas/elf/section17.d: Likewise.
* testsuite/gas/elf/section17.l: Likewise.
* testsuite/gas/elf/section17.s: Likewise.
* testsuite/gas/i386/unique.d: Likewise.
* testsuite/gas/i386/unique.s: Likewise.
* testsuite/gas/i386/x86-64-unique.d: Likewise.
* testsuite/gas/i386/i386.exp: Run unique and x86-64-unique.

ld/

PR gas/25380
* testsuite/ld-i386/pr22001-1c.S: Use "unique,N" in .section
directives.
* testsuite/ld-i386/tls-gd1.S: Likewise.
* testsuite/ld-x86-64/pr21481b.S: Likewise.

Automatic date update in version.in

elf/section13.s: Replace @nobits with %nobits

* testsuite/gas/elf/section13.s: Replace @nobits with %nobits.

moxie: don't force big-endian mode

Automatic date update in version.in

Update release making documentation

Move pending obsolete targets onto the definitely obsolete list

ubsan: frv: left shift of negative value

More non-bugs flagged by ubsan, unless you happen to be compiling for
a 1's complement host.

cpu/
* frv.cpu (f-u12): Multiply rather than left shift signed values.
(f-label16, f-label24): Likewise.
opcodes/
* frv-ibld.c: Regenerate.

gdb: Do not print empty-group regs when printing general ones

When the command "info registers" (same as "info registers general"),
is issued, _all_ the registers from a tdesc XML are printed. This
includes the registers with empty register groups (set as "") which
are supposed to be only printed by "info registers all" (or "info
all-registers").

This bug got introduced after all the overhauls that the
tdesc_register_in_reggroup_p() went through. You can see that the
logic of tdesc_register_in_reggroup_p() did NOT remain the same after
all those changes:

  git difftool c9c895b9666..HEAD -- gdb/target-descriptions.c

With the current implementation, when the reg->group is an empty
string, this function returns -1, while in the working revision
(c9c895b9666), it returned 0. This patch makes sure that the 0 is
returned again.

The old implementation of tdesc_register_in_reggroup_p() returned
-1 when "reggroup" was set to "all_reggroups" at line 4 below:

1  tdesc_register_reggroup_p (...)
2  {
3   ...
4   ret = tdesc_register_in_reggroup_p (gdbarch, regno, reggroup);
5   if (ret != -1)
6     return ret;
7
8   return default_register_reggroup_p (gdbarch, regno, reggroup);
9  }

As a result, the execution continued at line 8 and the
default_register_reggroup_p(..., reggroup=all_reggroups) would
return 1. However, with the current implementation of
tdesc_register_in_reggroup_p() that allows checking against any
arbitrary group name, it returns 0 when comparing the "reg->group"
against the string "all" which is the group name for "all_reggroups".
I have added a special check to cover this case and
"info all-registers" works as expected.

gdb/ChangeLog:

* target-descriptions.c (tdesc_register_in_reggroup_p): Return 0
when reg->group is empty and reggroup is not.

Change-Id: I9eaf9d7fb36410ed5684ae652fe4756b1b2e61a3

Automatic date update in version.in

[gdb/testsuite] Fix typo in gdb.server/server-kill-python.exp

Fix typo '$gdb_tst_name' -> '$gdb_test_name'.

gdb/testsuite/ChangeLog:

2020-02-01  Tom de Vries  <tdevries@suse.de>

* gdb.server/server-kill-python.exp: Fix $gdb_tst_name typo.

Change-Id: Iad050dab0e8aad2f2692e54e398021558250f1ac

nios2: Add BFD support for GOT-relative DW_EH_PE_datarel encodings

There's already existing logic to handle this on other targets, so
this patch just makes nios2 use it.

2020-01-31  Sandra Loosemore  <sandra@codesourcery.com>

bfd/
* elf-eh-frame.c (_bfd_elf_write_section_eh_frame): DW_EH_PE_datarel
encodings are relative to the GOT on nios2, too.

nios2: recognize %gotoff relocation in assembler

The nios2 ABI documentation lists %gotoff as assembler syntax for the
R_NIOS2_GOTOFF relocation, used to represent a 32-bit GOT-relative offset
in data sections.  This was previously unimplemented in GAS.

2020-01-31  Sandra Loosemore  <sandra@codesourcery.com>

gas/
* config/tc-nios2.c (nios2_cons): Handle %gotoff as well as
%tls_ldo.

Add missing ChangeLog for last patch

arm: PR gas/25472 Enable DSP instructions with +mve

We noticed +mve was not enabling DSP instructions as it should, reported in PR
25472.
The MVE architecture extension for Armv8.1-M Mainline implies DSP extensions.
This patch reflects that in the '+mve' command line option.

gas/ChangeLog:
2020-01-31  Andre Vieira  <andre.simoesdiasvieira@arm.com>

PR gas/25472
* config/tc-arm.c (armv8m_main_ext_table): Refactored +dsp adding.
(armv8_1m_main_ext_table): Refactored +dsp adding and enabled dsp for
+mve.
* testsuite/gas/arm/mve_dsp.d: New test.

Fix compile time build problem building the s390 assembler.

* config/tc-s390.c (s390_elf_suffix): Return ELF_SUFFIX_NONE
rather than BFD_RELOC_NONE.

[ARM]: Add support for vldmia/vldmdb/vstmia/vstmdb instructions in MVE.

This patch adds support for assembly instructions vldmia, vldmdb, vstmia
and vstmdb in MVE.  This instructions are already supported for Armv8-M
Floating-point Extension.

gas/ChangeLog:

2020-01-31  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

* config/tc-arm.c (fldmias): Moved inside "THUMB_VARIANT & arm_ext_v6t2"
to support VLDMIA instruction for MVE.
(fldmdbs): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VLDMDB
instruction for MVE.
(fstmias): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VSTMIA
instruction for MVE.
(fstmdbs): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VSTMDB
instruction for MVE.
* testsuite/gas/arm/mve-ldst.d: New test.
* testsuite/gas/arm/mve-ldst.s: Likewise.

Updated translations for some of the binutils sub-directories

x86: replace EXxmm_mdq by EXVexWdqScalar

There's no need to have two operand specifiers / enumerators for the
same purpose. This then renders xmm_mdq_mode unused.

x86: drop unused EXVexWdq / vex_w_dq_mode

aarch64: Fix MOVPRFX markup for bf16 conversions

bfcvt converts a .S input to a .H output, so any predicated movprfx
needs to operate on .S rather than .H.  In common with SVE2 narrowing
top operations, bfcvtnt doesn't accept movprfx.

2020-01-31  Richard Sandiford  <richard.sandiford@arm.com>

opcodes/
* aarch64-tbl.h (aarch64_opcode): Set C_MAX_ELEM for SVE bfcvt.
Remove C_SCAN_MOVPRFX for SVE bfcvtnt.

gas/
* testsuite/gas/aarch64/sve-bfloat-movprfx.s: Use .h rather than
.s for the movprfx.
* testsuite/gas/aarch64/sve-bfloat-movprfx.d: Update accordingly.
* testsuite/gas/aarch64/sve-movprfx_28.d,
* testsuite/gas/aarch64/sve-movprfx_28.l,
* testsuite/gas/aarch64/sve-movprfx_28.s: New test.

Fix ravenscar-thread.c for multi-target

ravenscar-thread.c needed a change to adapt to multi-target:
ravenscar_thread_target::mourn_inferior called the mourn_inferior
method on the target beneat -- but when the target beneath was the
remote target, this resulted in the ravenscar target being deleted.

Switching the order of the calls to unpush_target and the beneath's
mourn_inferior fixes this problem.

gdb/ChangeLog
2020-01-31  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c (ravenscar_thread_target::mourn_inferior):
Call beneath target's mourn_inferior after unpushing.

Change-Id: Ia80380515c403adc40505a6b3420c9cb35754370

gdb/tui: Disassembler scrolling of very small programs

In TUI mode, if the disassembly output for the program is less than
one screen long, then currently if the user scrolls down until on the
last assembly instruction is displayed and then tries to scroll up
using Page-Up, the display doesn't update - they are stuck viewing the
last line.

If the user tries to scroll up using the Up-Arrow, then the display
scrolls normally.

What is happening is on the Page-Up we ask GDB to scroll backward the
same number of lines as the height of the TUI ASM window.  The back
scanner, which looks for a good place to start disassembling, fails to
find a starting address which will provide the requested number of new
lines before we get back to the original starting address (which is
not surprising, our whole program contains less than a screen height
of instructions), as a result the back scanner gives up and returns
the original starting address.

When we scroll with Up-Arrow we only ask the back scanner to find 1
new instruction, which it manages to do, so this scroll works.

The solution here is, when we fail to find enough instructions, to
return the lowest address we did manage to find.  This will ensure we
jump to the lowest possible address in the disassembly output.

gdb/ChangeLog:

PR tui/9765
* tui/tui-disasm.c (tui_find_disassembly_address): If we don't
have enough lines to fill the screen, still return the lowest
address we found.

gdb/testsuite/ChangeLog:

PR tui/9765
* gdb.tui/tui-layout-asm-short-prog.S: New file.
* gdb.tui/tui-layout-asm-short-prog.exp: New file.

Change-Id: I6a6a7972c68a0559e9717fd8d82870b669a40af3

gdb/tui: Update help text for scroll commands

GDB has some commands ('+', '-', '<', and '>') for scrolling the SRC
and ASM TUI windows from the CMD window, however the help text for
these commands lists the arguments in the wrong order.

This commit updates the help text to match how GDB actually works, and
also extends the text to describe what the arguments mean, and what
the defaults are.

There should be no change in GDBs functionality after this commit.

gdb/ChangeLog:

* tui/tui-win.c (_initialize_tui_win): Update help text for '+',
'-', '<', and '>' commands.

Change-Id: Ib2624891de1f4ba983838822206304e4c3ed982e

Tidy bfd.pot

This patch removes the leak of Nick's source directory into bfd.pot,
and emits #line for some generated files so that those files aren't
referenced by comments in the .pot file.  You can see both of these
effects in the following diff.  I've also removed use of an
unnecessary temp file in the make rules.

@@ -92,10 +92,8 @@ msgstr ""
 #: elf64-nfp.c:238 elf64-ppc.c:1014 elf64-ppc.c:1349 elf64-ppc.c:1358
 #: elf64-s390.c:328 elf64-s390.c:378 elf64-x86-64.c:285 elfn32-mips.c:3786
 #: elfxx-ia64.c:324 elfxx-riscv.c:955 elfxx-sparc.c:589 elfxx-sparc.c:639
-#: elfxx-tilegx.c:912 elfxx-tilegx.c:952
-#: /work/sources/binutils/current/bfd/elfnn-aarch64.c:2215
-#: /work/sources/binutils/current/bfd/elfnn-aarch64.c:2313 elf32-ia64.c:214
-#: elf32-ia64.c:3862 elf64-ia64.c:214 elf64-ia64.c:3862
+#: elfxx-tilegx.c:912 elfxx-tilegx.c:952 elfnn-aarch64.c:2215
+#: elfnn-aarch64.c:2313 elfnn-ia64.c:214 elfnn-ia64.c:3862
 #, c-format
 msgid "%pB: unsupported relocation type %#x"
 msgstr ""

* Makefile.am (elf32-target.h, elf64-target.h): Don't use a temp
file.  Use $< and $@ in rules.
(elf32-aarch64.c, elf64-aarch64.c): Likewise.
(elf32-ia64.c, elf64-ia64.c): Likewise.
(elf32-riscv.c, elf64-riscv.c): Likewise.
(peigen.c, pepigen.c, pex64igen.c): Likewise.
(elf32-aarch64.c, elf64-aarch64.c): Don't emit $srcdir on #line.
(elf32-riscv.c, elf64-riscv.c): Likewise, and use $(SED).
(elf32-ia64.c, elf64-ia64.c): Do emit #line.
(peigen.c, pepigen.c, pex64igen.c): Likewise.
* Makefile.in: Regenerate.

OOM in setup_group

We alloc, seek and read using section sizes in object files.  Fuzzed
objects can have silly sizes, but that's OK if the system supports
memory over-commit.  The read fails because we hit EOF and that
usually results in a graceful exit.

But if we memset before the read then the invalid size results in
attempting to write to a huge number of memory pages, and an eventual
Out Of Memory after probably swapping like crazy.  So don't memset.
There really isn't a need to clear the section contents anyway.  All
bytes are written with a good object file by the read and following
loop converting section index in target order to ELF section header
pointer, and the only untidy bytes are the 4 bytes past the group
flags when pointers are 8 bytes.  Those don't matter but the patch
clears them for anyone poking around in a debugger.  On error paths
it's as good to free section contents as it is to clear them.

Noticed when looking at PR4110 fourth test case.

PR 4110
* elf.c (setup_group): Don't clear entire section contents,
just the padding after group flags.  Release alloc'd memory
after a seek or read failure.

Automatic date update in version.in

x86: prevent undue use of GOT32X and alike relocations

Comparison of i.tm.base_opcode against particular but not sufficiently
specific values needs to be accompanied by other qualification. Exclude
VEX and alike encodings here, and also exclude all forms of prefixes
explicitly specified in the opcodes table. While using @GOT with such
insns may not be very useful, it also isn't with e.g. ADC and SBB, yet
these get explicitly listed in comments as supported.

ld/doc: drop blank between @option and brace

Commit 9e7028aa1e78 ("PowerPC64 __tls_get_addr_desc") introduced a use
of @option which apparently newer makeinfo tolerates, but older ones
reject. Drop the unnecessary (a per all other uses of @option) blank.

ubsan: m32c: left shift of negative value

More nonsense fixing "bugs" with left shifts of signed values.  Yes,
the C standard does say this is undefined (and right shifts of signed
values are implementation defined BTW) but in practice there is no
problem with current machines.  1's complement is a thing of the past.

cpu/
* m32c.cpu (f-src32-rn-unprefixed-QI): Shift before inverting.
(f-src32-rn-prefixed-QI, f-dst32-rn-unprefixed-QI): Likewise.
(f-dst32-rn-prefixed-QI): Likewise.
(f-dsp-32-s32): Mask before shifting left.
(f-dsp-48-u32, f-dsp-48-s32): Likewise.
(f-bitbase32-16-s11-unprefixed): Multiply signed field rather than
shifting left.
(f-bitbase32-24-s11-prefixed, f-bitbase32-24-s19-prefixed): Likewise.
(h-gr-SI): Mask before shifting.
opcodes/
* m32c-ibld.c: Regenerate.

Identify reproducible builds in 'objdump -p' output for PE files

These are produced by MSVC when the '/Brepro' flag is used.

To quote from the PE specification [1]:

"The presence of an entry of type IMAGE_DEBUG_TYPE_REPRO indicates the
PE file is built in a way to achieve determinism or reproducibility. If
the input does not change, the output PE file is guaranteed to be
bit-for-bit identical no matter when or where the PE is produced.
Various date/time stamp fields in the PE file are filled with part or
all the bits from a calculated hash value that uses PE file content as
input, and therefore no longer represent the actual date and time when a
PE file or related specific data within the PE is produced. The raw data
of this debug entry may be empty, or may contain a calculated hash value
preceded by a four-byte value that represents the hash value length."

[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

bfd/ChangeLog:

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

* peXXigen.c (pe_is_repro): New function.
(_bfd_XX_print_private_bfd_data_common): Note timestamp is
actually a build hash if PE_IMAGE_DEBUG_TYPE_REPRO is present.

Add some new PE_IMAGE_DEBUG_TYPE values

IMAGE_DEBUG_TYPE_REPRO is defined in the latest version of the PE
specification [1]. The others are defined in Windows SDK headers and/or
reported by DUMPBIN.

[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

bfd/ChangeLog:

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

* peXXigen.c (debug_type_names): Add names for new debug data type
values.

include/ChangeLog:

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

* coff/internal.h (PE_IMAGE_DEBUG_TYPE_VC_FEATURE)
(PE_IMAGE_DEBUG_TYPE_POGO, PE_IMAGE_DEBUG_TYPE_ILTCG)
(PE_IMAGE_DEBUG_TYPE_MPX, PE_IMAGE_DEBUG_TYPE_REPRO): Add.

Bugfixes for pe_print_debugdata()

Use a separate iteration variable for inner loop (:blush:).  This
generally prevented any debug directory entries after a
IMAGE_DEBUG_TYPE_CODEVIEW entry from being reported.

Don't leak the memory allocated for the section containing the debug
directory.

bfd/ChangeLog:

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

* peXXigen.c (pe_print_debugdata): Fix the iteration variable for
inner loop.  Fix a memory leak.

cpu,opcodes,gas: fix neg and neg32 instructions in BPF

This patch fixes the neg/neg32 BPF instructions, which have K (=0)
instead of X (=1) in their header source bit, despite operating on
registes.

cpu/ChangeLog:

2020-01-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

* bpf.cpu (define-alu-insn-un): The unary BPF instructions
(neg and neg32) use OP_SRC_K even if they operate only in
registers.

opcodes/ChangeLog:

2020-01-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

* bpf-opc.c: Regenerate.

gas/ChangeLog:

2020-01-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

* testsuite/gas/bpf/alu.d: Update expected opcode for `neg'.
* testsuite/gas/bpf/alu-be.d: Likewise.
* testsuite/gas/bpf/alu32.d: Likewise for `neg32'.
* testsuite/gas/bpf/alu32-be.d: Likewise.

x86-64: honor vendor specifics for near RET

While vendors agree about default operand size (64 bits) and hence
unavilability of a 32-bit form, AMD honors a 16-bit operand size
override (0x66) while Intel doesn't.

x86-64: also diagnose far returns / IRET with ambiguous operand size

Other than near returns these default to 32-bit operand size, and hence
it isn't really unlikely that 64-bit forms are meant. Hence these should
have disambiguating suffixes. In Intel mode, however, don't error in
these cases unconditionally - MASM accepts these without suffix _and_
without warning.

x86: drop further pointless/bogus DefaultSize

- 64-bit CALL permitting just a single operand size doesn't need it.
- FLDENV et al should never have had it.

It remains suspicious that a number of 64-bit only insns continue to
have the attribute, despite this being intended for .code16gcc handling
only.

ubsan: tic4x: left shift cannot be represented in type 'int'

The patch also fixes a case where libopcodes built for a 64-bit
bfd_vma may print different results to libopcodes built for a 32-bit
bfd_vma.

* tic4x-dis.c (tic4x_dp): Make unsigned.

Remove need to clear obj_coff_keep_syms in coff object_p

* coffgen.c (coff_real_object_p): Don't clear obj_coff_keep_syms
or obj_coff_keep_strings here.
(coff_get_normalized_symtab): Free external syms directly.
* xcofflink.c (xcoff_link_input_bfd): Restore obj_coff_keep_syms
on error exit path.

Automatic date update in version.in

Fix -Werror-stringop error on infcmd.c:construct_inferior_arguments

While testing a GCC 10 build of our git HEAD, Sergio noticed an error
triggered by -Werror-stringop on
infcmd.c:construct_inferior_arguments.  One of the things the function
does is calculate the length of the string that will hold the
inferior's arguments.  GCC warns us that 'length' can be 0, which can
lead to undesired behaviour:

../../gdb/infcmd.c: In function 'char* construct_inferior_arguments(int, char**)':
../../gdb/infcmd.c:369:17: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  369 |       result[0] = '\0';
      |       ~~~~~~~~~~^~~~~~
../../gdb/infcmd.c:368:33: note: at offset 0 to an object with size 0 allocated by 'xmalloc' here
  368 |       result = (char *) xmalloc (length);
      |                         ~~~~~~~~^~~~~~~~

The solution here is to assert that 'argc' is greater than 0 on entry,
which makes GCC understand that the loops always run at least once,
and thus 'length' is always > 0.

Tested by rebuilding.

gdb/ChangeLog:
2020-01-29  Pedro Alves  <palves@redhat.com>
    Sergio Durigan Junior  <sergiodj@redhat.com>

* infcmd.c (construct_inferior_arguments): Assert that
'argc' is greater than 0.

Change-Id: Ide8407cbedcb4921de1843a6a15bbcb7676c7d26

Adjust src-release.sh's getver due to gdbsupport's move to toplevel

The move of gdbsupport to the top level directory requires a small
change to src-release.sh's "getver" function, which is responsible for
determining the version string that will be appended to the release
tarball: now the create-version.sh script lives under ./gdbsupport,
and not under gdb/gdbsupport anymore.

This patch unbreaks the snapshot generation, which hasn't been working
since January 14th.

ChangeLog:
2020-01-29  Sergio Durigan Junior  <sergiodj@redhat.com>

* src-release.sh (getver): Look for gdbsupport's
create-version.sh script at the current directory if tool is
"gdb".

Change-Id: Id3b8bed6583a1aaa120c07009366f6c94a62d5db

gdbserver: Fix whitespace configure.srv damage for `i[34567]86-*-mingw*'

Fix fallout from commit 42cd72aa0279 ("gdbserver: Make `make TAGS'
actually work") add a missing newline to configure.srv for
`i[34567]86-*-mingw*'.

gdb/gdbserver/
* configure.srv <i[34567]86-*-mingw*>: Fix whitespace damage.

Fix configure.srv error for Linux on PowerPC

An error in commit 42cd72aa0279520384327a1f6d0ebd2eb2200645 caused
srv_tgtobj to be overwritten and linux-ppc-low.o to be missed when
linking gdbserver for Linux on PowerPC.  This patch fixes the error.

gdb/gdbserver/ChangeLog:
2020-01-29  Pedro Franco de Carvalho  <pedromfc@linux.ibm.com>

* configure.srv (powerpc*-*-linux*): Use srv_tgtobj in second
assignment instead of srv_linux_obj.

Test handling of additional brk instruction patterns

New in v5:

- Use gdb_test_name for gdb_test_multiple.
- Use gdb_assert.
- Verify count matches the expected sigtraps exactly.

New in v4:

- Fix formatting nit in gdb/testsuite/gdb.arch/aarch64-brk-patterns.c.

New in v3:

- Minor formatting and code cleanups.
- Added count check to validate number of brk SIGTRAP's.
- Moved count to SIGTRAP check conditional block.

This test exercises the previous patch's code and makes sure GDB can
properly get a SIGTRAP from various brk instruction patterns.

GDB needs to be able to see the program exiting normally. If GDB doesn't
support the additional brk instructions, we will see timeouts.

We bail out with the first timeout since we won't be able to step through
the program breakpoint anyway, so it is no use carrying on.

gdb/testsuite/ChangeLog:

2020-01-29  Luis Machado  <luis.machado@linaro.org>

* gdb.arch/aarch64-brk-patterns.c: New source file.
* gdb.arch/aarch64-brk-patterns.exp: New test.

Recognize more program breakpoint patterns

New in v3:

- Code cleanups based on reviews.

New in v2:

- Fixed misc problems based on reviews.
- Switched to using gdbarch_program_breakpoint_here_p as opposed to
gdbarch_insn_is_breakpoint.
- Fixed matching of brk instructions. Previously the mask was incorrect, which
was showing up as a few failures in the testsuite. Now it is clean.
- New testcase (separate patch).
- Moved program_breakpoint_here () to arch-utils.c and made it the default
implementation of gdbarch_program_breakpoint_here_p.

--

It was reported to me that program breakpoints (permanent ones inserted into
the code itself) other than the one GDB uses for AArch64 (0xd4200000) do not
generate visible stops when continuing, and GDB will continue spinning
infinitely.

This happens because GDB, upon hitting one of those program breakpoints, thinks
the SIGTRAP came from a delayed breakpoint hit...

(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk     #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14198)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14198
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14198.14198.0 [process 14198],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14198.14198.0 [process 14198],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14198.14198.0 [process 14198],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14198.14198.0 [process 14198],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: delayed software breakpoint trap, ignoring
infrun: no stepping, continue
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14198.14198.0 [process 14198],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
...

... which is not the case.

If the program breakpoint is one GDB recognizes, then it will stop when it
hits it.

(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk     #0x0
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 14193)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 14193
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14193] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   14193.14193.0 [process 14193],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun:   process 14193 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun:   process 14193 not executing
infrun: stop_all_threads done

Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk_0.c:7
7        asm("brk %0\n\t" ::"n"(0x0));
infrun: infrun_async(0)

Otherwise GDB will keep trying to resume the inferior and will keep
seeing the SIGTRAP's, without stopping.

To the user it appears GDB has gone into an infinite loop, interruptible only
by Ctrl-C.

Also, windbg seems to use a different variation of AArch64 breakpoint compared
to GDB. This causes problems when debugging Windows on ARM binaries, when
program breakpoints are being used.

The proposed patch creates a new gdbarch method (gdbarch_program_breakpoint_here_p)
that tells GDB whether the underlying instruction is a breakpoint instruction
or not.

This is more general than only checking for the instruction GDB uses as
breakpoint.

The existing logic is still preserved for targets that do not implement this
new gdbarch method.

The end result is like so:

(gdb) x/i $pc
=> 0x4005c0 <problem_function>: brk     #0x90f
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 16417)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 16417
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 16417] at 0x4005c0
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   16417.16417.0 [process 16417],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: stop_pc = 0x4005c0
infrun: random signal (GDB_SIGNAL_TRAP)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun:   process 16417 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun:   process 16417 not executing
infrun: stop_all_threads done

Program received signal SIGTRAP, Trace/breakpoint trap.
problem_function () at brk.c:7
7        asm("brk %0\n\t" ::"n"(0x900 + 0xf));
infrun: infrun_async(0)

gdb/ChangeLog:

2020-01-29  Luis Machado  <luis.machado@linaro.org>

* aarch64-tdep.c (BRK_INSN_MASK): Define to 0xffe0001f.
(BRK_INSN_MASK): Define to 0xd4200000.
(aarch64_program_breakpoint_here_p): New function.
(aarch64_gdbarch_init): Set gdbarch_program_breakpoint_here_p hook.
* arch-utils.c (default_program_breakpoint_here_p): Moved from
breakpoint.c.
* arch-utils.h (default_program_breakpoint_here_p): Moved from
breakpoint.h
* breakpoint.c (bp_loc_is_permanent): Changed return type to bool and
call gdbarch_program_breakpoint_here_p.
(program_breakpoint_here): Moved to arch-utils.c, renamed to
default_program_breakpoint_here_p, changed return type to bool and
simplified.
* breakpoint.h (program_breakpoint_here): Moved prototype to
arch-utils.h, renamed to default_program_breakpoint_here_p and changed
return type to bool.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (program_breakpoint_here_p): New method.
* infrun.c (handle_signal_stop): Call
gdbarch_program_breakpoint_here_p.

testsuite, cp: add expected failures to pass-by-ref tests for certain compilers

There exist expected failures in the pass-by-ref.exp and
pass-by-ref-2.exp tests based on the GCC and Clang version.

* GCC version <= 6 and Clang do not emit DW_AT_deleted and
  DW_AT_defaulted.

* Clang version >= 7 emits DW_AT_calling_convention, which helps the
  debugger make the right calling convention decision in some cases
  despite lacking the 'defaulted' and 'deleted' attributes.

Mark the related tests as XFAIL based on the compiler version.

Tested on X86_64 using GCC 5.5.0, 6.5.0, 7.4.0, 8.3.0, 9.2.1;
and Clang 5.0.1, 6.0.0, 7.0.0, 8.0.0, 9.0.1, 10.0.0.

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

* gdb.cp/pass-by-ref-2.exp: Mark some tests as XFAIL based on the
GCC/Clang version.
* gdb.cp/pass-by-ref.exp: Ditto.

Change-Id: I1d8440aa438049f7c4da7f4f76f201c48550f1e4

[gdb/testsuite] Fix gdb.threads/watchpoint-fork.exp race

I ran into:
...
Thread 3.1 "watchpoint-fork" hit Breakpoint 3, marker () at \
  watchpoint-fork-mt.c:42^M
42      }^M
(gdb) parent2: 1945^M

FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: breakpoint (A) \
  after the second fork (timeout)
...
The problem is that the FAILing gdb_test expects '(gdb) ' to be the last thing
printed, but the inferior prints something after that.

A similar FAIL is described in the sources in watchpoint-fork-parent.c:
...
      printf ("child%d: %d\n", nr, (int) getpid ());
      /* Delay to get both the "child%d" and "parent%d" message printed
        without a race breaking expect by its endless wait on `$gdb_prompt$':
         Breakpoint 3, marker () at watchpoint-fork.c:33
         33      }
         (gdb) parent2: 14223  */
      i = sleep (1);
...

I noticed that while the executables print output, the output is not verified in
the test-case, so it's merely debug output.

Fix this by:
- guarding the prints in the executables (as well as related
  sleep and setbuf calls) with #if DEBUG, and
- compiling by default with DEBUG=0.

gdb/testsuite/ChangeLog:

2020-01-29  Tom de Vries  <tdevries@suse.de>

* gdb.threads/watchpoint-fork-child.c: Guard prints with #if DEBUG.
* gdb.threads/watchpoint-fork-mt.c: Same.
* gdb.threads/watchpoint-fork-parent.c: Same.
* gdb.threads/watchpoint-fork-st.c: Same.
* gdb.threads/watchpoint-fork.exp: Compile with DEBUG=0.

Change-Id: I63efd4c7771f96b5f5cd87ef2ab36795484ae2be

PR25477, ld 2.34 tries to load ${prefix}/etc/ld.so.conf

PR 25477
* ldelf.c (ldelf_check_ld_so_conf): Add prefix parameter and
correct concat.
(ldelf_after_open): Add prefix parameter.
* ldelf.h (ldelf_after_open): Update prototype.
* emultempl/elf.em (gld${EMULATION_NAME}_after_open): Pass $prefix
to ldelf_after_open.
* Makefile.am: Correct z80 dependencies.
* Makefile.in: Regenerate.

Automatic date update in version.in

Fix library segment-address for 64bit values

The address was written as a long value, but long is always a 32bit value
on Windows, which lead to truncated addresses.
The solution was to use paddress instead.

gdb/gdbserver/ChangeLog:

2020-01-28  Hannes Domani  <ssbssa@yahoo.de>

* server.c (handle_qxfer_libraries): Write segment-address with
paddress.

Improve warning message from debuginfod support in readelf.

* readelf.c (get_build_id): Simplify warning message about corrupt
notes encountered whilst scanning for the build-id.

Don't report symbol lookup failure in first phase of linking

Until the symbol table is created, symbols can't be created.

* ldexp.c (fold_name): Don't print bfd_link_hash_lookup failed
in first phase.

Automatic date update in version.in

RISC-V: Fix gdbserver problem with handling arch strings.

Maciej reported a problem found by his RISC-V gdbserver port.
warning: while parsing target description (at line 4): Target description specified unknown architecture "riscv:rv64id"
warning: Could not load XML target description; ignoring

We only have two arches defined, riscv:rv32 and riscv:rv64.  Both bfd and
gdb are creating arch strings that have extension letters added to the base
architecture.  The bfd_default_scan function requires an exact match, so
these strings fail to map to a bfd_arch.  I think we should ignore the
extension letters in a RISC-V specific scan function.

bfd/
* cpu-riscv.c (riscv_scan): New.
(N): Change bfd_default_scan to riscv_scan.

Change-Id: I096476705e1da5cb8934c5005b1eed2a8989f7a7

Harden gdb.base/step-over-syscall.exp

New in v3:
- Verify if the syscall number matches what is expected for the target.
- Used gdb_assert for one more check.

New in v2:

- Set initial values to -1 instead of 0.
- Rewrote RE to prevent unexpected matching when parsing one character at a
  time.
- Used gdb_assert for an additional check.
- Validated with check-read1

There are a couple problems with this test.

First
--

gdb.base/step-over-syscall.exp records the address of a syscall instruction
within fork/vfork/clone functions and also the address of the instruction
after that syscall instruction.

It uses these couples addresses to make sure we stepped over a syscall
instruction (fork/vfork/clone events) correctly.

The way the test fetches the addresses of the instructions is by stepi-ing
its way through the fork/vfork/clone functions until it finds a match for
a syscall. Then it stepi's once again to get the address of the next
instruction.

This assumes that stepi-ing over a syscall is working correctly and landing
in the right PC. This is not the case for AArch64/Linux, where we're
landing a couple instructions after the syscall in some cases.

The following patch lets the test execute as before, but adds a new instruction
address check using the x command as opposed to stepi.

I didn't want to change how the test works since we may also be
interested in checking if stepi-ing over the syscall under different
conditions (displaced stepping on/off) yields the same results. I don't
feel strongly about this, so i'm OK with changing how we compare PC's for
the entire test if folks decide it is reasonable.

Second
--

FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: continue to vfork (3rd time) (the program exited)
FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: continue to syscall insn vfork (the program is no longer running)
FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (the program is no longer running)

Depending on the glibc version we may have different code generated for the
fork/vfork/clone functions.

I ran into the situation where vfork for newer glibc's on AArch64/Linux is
very short, so "break vfork" will put a breakpoint right at the syscall
instruction, which is something the testcase isn't expecting (a off-by-1
of sorts).

The patch adds extra code to handle this case. If the test detects we're
already sitting at a syscall instruction, it records the address and moves
on to record the address after that particular instruction.

Another measure is to "break *$syscall" instead of "break $syscall". That
guarantees we're stopping at the first instruction of the syscall function,
if it ever happens that the syscall instruction is the first instruction of
those functions.

With these changes i can fix some failures for aarch64-linux-gnu and also
expose the problems i've reported here:

https://sourceware.org/ml/gdb-patches/2019-12/msg01071.html

These tests now fail for aarch64-linux-gnu (patch for this is going through
reviews):

FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: pc after stepi matches insn addr after syscall
FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=on: pc after stepi matches insn addr after syscall

gdb/testsuite/ChangeLog:

2020-01-27  Luis Machado  <luis.machado@linaro.org>

* gdb.base/step-over-syscall.exp (setup): Check if we're already
sitting at a syscall instruction when we hit the syscall function's
breakpoint.
Check PC against one obtained with the x command.
Validate syscall number.
(step_over_syscall): Don't continue to the syscall instruction if
we're already there.

Fix objcopy --merge-notes dependency on qsort implementation behavior.

binutils/
* objcopy.c (compare_gnu_build_notes): Fix comparison results
for overlapping ranges so that (A == B) == (B == A) holds.

Remove cpu-plugin.c

After commit 999d6dff80f cpu-plugin.c is no longer begin used.

* Makefile.am (ALL_MACHINES): Remove cpu-plugin.lo.
(ALL_MACHINES_CFILES): Remove cpu-plugin.c.
* Makefile.in: Regenerate.
* cpu-plugin.c: Remove.
* archures.c (enum bfd_architecture): Remove bfd_arch_plugin.
(bfd_plugin_arch): Remove declaration.
* bfd-in2.h: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

x86-64: Properly encode and decode movsxd

movsxd is a 64-bit only instruction.  It supports both 16-bit and 32-bit
destination registers.  Its AT&T mnemonic is movslq which only supports
64-bit destination register.  There is also a discrepancy between AMD64
and Intel64 on movsxd with 16-bit destination register.  AMD64 supports
32-bit source operand and Intel64 supports 16-bit source operand.

This patch updates movsxd encoding and decoding to alow 16-bit and 32-bit
destination registers.  It also handles movsxd with 16-bit destination
register for AMD64 and Intel 64.

gas/

PR binutils/25445
* config/tc-i386.c (check_long_reg): Also convert to QWORD for
movsxd.
* doc/c-i386.texi: Add a node for AMD64 vs. Intel64 ISA
differences.  Document movslq and movsxd.
* testsuite/gas/i386/i386.exp: Run PR binutils/25445 tests.
* testsuite/gas/i386/x86-64-movsxd-intel.d: New file.
* testsuite/gas/i386/x86-64-movsxd-intel64-intel.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64-inval.l: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64-inval.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd-inval.l: Likewise.
* testsuite/gas/i386/x86-64-movsxd-inval.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd.s: Likewise.

opcodes/

PR binutils/25445
* i386-dis.c (MOVSXD_Fixup): New function.
(movsxd_mode): New enum.
(x86_64_table): Use MOVSXD_Fixup and movsxd_mode on movsxd.
(intel_operand_size): Handle movsxd_mode.
(OP_E_register): Likewise.
(OP_G): Likewise.
* i386-opc.tbl: Remove Rex64 and allow 32-bit destination
register on movsxd.  Add movsxd with 16-bit destination register
for AMD64 and Intel64 ISAs.
* i386-tbl.h: Regenerated.

Replace deprecated tcl case statements with switch statements

binutils/
* testsuite/lib/binutils-common.exp (big_or_little_endian): Replace
case statement with switch statement.
gas/
* testsuite/gas/all/gas.exp: Replace case statements with switch
statements.
* testsuite/gas/elf/elf.exp: Likewise.
* testsuite/gas/macros/macros.exp: Likewise.
* testsuite/lib/gas-defs.exp: Likewise.
ld/
* testsuite/ld-elfvers/vers.exp: Replace case statements with
switch statements.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.

AArch64: Fix cfinv disassembly issues

This fixes the preferred disassembly for cfinv.  The Armv8.4-a instruction
overlaps with the possible encoding space for msr.  This because msr allows you
to use unallocated encoding space using the general sA_B_cC_cD_E form.

However when an encoding does become allocated then we need to ensure that it's
used as the preferred disassembly.  The problem with cfinv is that its mask has
all bits sets because it has no arguments.

This causes issues for the Alias resolver in gas as it uses the mask to build
alias graph.  In this case it can't do it since it thinks almost everything
would alias with cfinv.  So instead we can only fix this by moving cfinv before
msr.

gas/ChangeLog:

PR 25403
* testsuite/gas/aarch64/armv8_4-a.d: Add cfinv.
* testsuite/gas/aarch64/armv8_4-a.s: Likewise.

opcodes/ChangeLog:

PR 25403
* aarch64-tbl.h (struct aarch64_opcode): Re-order cfinv.
* aarch64-asm-2.c: Regenerate
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.

Two minor changes in ctfread.c

I noticed a couple of minor issues in ctfread.c, both fixed by this
patch:

* ctf_fp_info was not indented properly; and
* _initialize_ctfread is no longer needed

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* ctfread.c (struct ctf_fp_info): Reindent.
(_initialize_ctfread): Remove.

Change-Id: I72707b74bc59e6e426b3a7bc8843d96c0d786f1e

Mark all weak aliases for copy relocations

bfd/
PR ld/25458
* elflink.c (_bfd_elf_gc_mark_rsec): Mark all weak aliases.
ld/
PR ld/25458
* testsuite/ld-elf/pr25458.map: New file.
* testsuite/ld-elf/pr25458.rd: Likewise.
* testsuite/ld-elf/pr25458a.s: Likewise.
* testsuite/ld-elf/pr25458b.s: Likewise.
* testsuite/ld-elf/shared.exp: Run PR ld/25458 test.

Automatic date update in version.in

Virtualize "readin" and "compunit_symtab"

This patch removes the "readin" and "compunit_symtab" members from
partial_symtab, replacing them with methods.  Then it introduces a new
"standard_psymtab" class, which restores these members; and changes
the symbol readers to use this intermediate class as the base class of
their partial symtab subclasses.

The reason for this is to make it possible for a symbol reader to
implement an alternate mapping between partial and full symbol tables.
This is important in order to be able to share psymtabs across
objfiles -- whether a psymtab has been "readin" is objfile-dependent,
as are the pointers to the full symbol tables.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* psymtab.c (partial_map_expand_apply)
(psym_find_pc_sect_compunit_symtab, psym_lookup_symbol)
(psymtab_to_symtab, psym_find_last_source_symtab, dump_psymtab)
(psym_print_stats, psym_expand_symtabs_for_function)
(psym_map_symbol_filenames, psym_map_matching_symbols)
(psym_expand_symtabs_matching)
(partial_symtab::read_dependencies, maintenance_info_psymtabs)
(maintenance_check_psymtabs): Use new methods.
* psympriv.h (struct partial_symtab) <readin_p,
get_compunit_symtab>: New methods.
<readin, compunit_symtab>: Remove members.
(struct standard_psymtab): New.
(struct legacy_psymtab): Derive from standard_psymtab.
* dwarf2read.h (struct dwarf2_psymtab): Derive from
standard_psymtab.
* ctfread.c (struct ctf_psymtab): Derive from standard_psymtab.

Change-Id: Idb923f196d7e03bf7cb9cfc8134ed06dd3f211ce

Consolidate partial symtab dependency reading

Most of the symbol readers have code to iterate over a partial symtabs
dependencies, expanding each one and optionally printing a message.
Now that the "second-stage" psymtab expansion is available as a
method, these implementations can all be merged.

This patch also changes a couple more warnings into assertions.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_psymtab_to_symtab_1): Call
read_dependencies.  Add assert.
* psymtab.c (partial_symtab::read_dependencies): New method.
* psympriv.h (struct partial_symtab) <read_dependencies>: New
method.
* mdebugread.c (psymtab_to_symtab_1): Call read_dependencies.
* dwarf2read.c (dwarf2_psymtab::expand_psymtab): Call
read_dependencies.
* dbxread.c (dbx_psymtab_to_symtab_1): Call read_dependencies.
Add assert.

Change-Id: I8151e05677794e90223edc1a4cb70f7f69137d46

Introduce partial_symtab::expand_psymtab method

The symbol readers generally used two functions to expand a partial
symtab: an outer function (now the "read_symtab" method), and an inner
function, typically named something like "psymtab_to_symtab".

This patch changes this second step to be a method on partial_symtab,
and updates all the callers.  For legacy_psymtab, a new function
pointer member is introduced.

This patch enables a subsequent cleanup.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_psymtab_to_symtab_1): Change argument order.
Call expand_psymtab.
(xcoff_read_symtab): Call expand_psymtab.
(xcoff_start_psymtab, xcoff_end_psymtab): Set
legacy_expand_psymtab.
* psympriv.h (struct partial_symtab) <expand_psymtab>: New
method.
(struct legacy_psymtab) <expand_psymtab>: Implement.
<legacy_expand_psymtab>: New member.
* mdebugread.c (mdebug_read_symtab): Call expand_psymtab.
(parse_partial_symbols): Set legacy_expand_psymtab.
(psymtab_to_symtab_1): Change argument order.  Call
expand_psymtab.
(new_psymtab): Set legacy_expand_psymtab.
* dwarf2read.h (struct dwarf2_psymtab) <expand_psymtab>: Declare.
* dwarf2read.c (dwarf2_psymtab::read_symtab): Call
expand_psymtab.
(dwarf2_psymtab::expand_psymtab): Rename from
psymtab_to_symtab_1.  Call expand_psymtab.
* dbxread.c (start_psymtab): Set legacy_expand_psymtab.
(dbx_end_psymtab): Likewise.
(dbx_psymtab_to_symtab_1): Change argument order. Call
expand_psymtab.
(dbx_read_symtab): Call expand_psymtab.
* ctfread.c (struct ctf_psymtab) <expand_psymtab>: Declare.
(ctf_psymtab::expand_psymtab): Rename from psymtab_to_symtab.
(ctf_psymtab::read_symtab): Call expand_psymtab.

Change-Id: Ic39a2d7aa7b424088d910b59dbd21271fa1c3430

Consolidate psymtab "Reading" messages

Each symbol reader implemented its own "Reading..." messages, and most
of them double-checked that a previously-expanded psymtab could not be
re-read.

This patch consolidates the message-printing, and changes these checks
into asserts.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_read_symtab): Remove prints.  Add assert.
* psymtab.c (psymtab_to_symtab): Print verbose "Reading"
messages.
* mdebugread.c (mdebug_read_symtab): Remove prints.
* dwarf2read.c (dwarf2_psymtab::read_symtab): Remove prints.  Add
assert.
* dbxread.c (dbx_read_symtab): Remove prints.  Add assert.

Change-Id: I795be9710d42708299bb7b44972cffd27aec9413

Introduce partial_symtab::read_symtab method

This introduces a new partial_symtab::read_symtab method, and updates
the symbol readers to subclass partial_symtab and implement this
method.  The old read_symtab and read_symtab_private members are
removed.

In practice, only DWARF and CTF are truly updated to take advantage of
the new setup.  The other symbol readers are less actively maintained,
and so this patch also introduces a "legacy_psymtab", which
essentially works the same way as the old partial_symtab.

(Note that, without more knowledge of the interaction between these
symbol readers, fixing this to remove the new (small) overhead is not
trivial, because these readers copy the read_symtab pointer between
partial symtabs.)

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (this_symtab_psymtab, read_xcoff_symtab)
(xcoff_psymtab_to_symtab_1, xcoff_read_symtab)
(xcoff_start_psymtab, xcoff_end_psymtab, scan_xcoff_symtab): Use
legacy_symtab.
* stabsread.h (dbx_end_psymtab): Use legacy_symtab.
* psymtab.c (psymtab_to_symtab): Call method.
(dump_psymtab): Update.
* psympriv.h (struct partial_symtab): Add virtual destructor.
<read_symtab>: New method.
(struct legacy_symtab): New.
* mdebugread.c (mdebug_read_symtab): Use legacy_psymtab.
(struct pst_map) <pst>: Now a legacy_psymtab.
(parse_procedure, parse_partial_symbols, psymtab_to_symtab_1)
(new_psymtab): Use legacy_psymtab.
* dwarf2read.h (struct dwarf2_psymtab): New.
(struct dwarf2_per_cu_data) <psymtab>: Use it.
* dwarf2read.c (dwarf2_create_include_psymtab)
(dwarf2_build_include_psymtabs, create_type_unit_group)
(create_partial_symtab, process_psymtab_comp_unit_reader)
(build_type_psymtabs_reader, build_type_psymtab_dependencies)
(set_partial_user): Use dwarf2_psymtab.
(dwarf2_psymtab::read_symtab): Rename from dwarf2_read_symtab.
(psymtab_to_symtab_1, process_full_comp_unit)
(process_full_type_unit, dwarf2_ranges_read)
(dwarf2_get_pc_bounds, psymtab_include_file_name)
(dwarf_decode_lines): Use dwarf2_psymtab.
* dwarf-index-write.c (psym_index_map): Use dwarf2_psymtab.
(add_address_entry_worker, write_one_signatured_type)
(recursively_count_psymbols, recursively_write_psymbols)
(write_one_signatured_type, psyms_seen_size, write_gdbindex)
(write_debug_names): Likewise.
* dbxread.c (struct header_file_location): Take a legacy_psymtab.
<pst>: Now a legacy_psymtab.
(find_corresponding_bincl_psymtab): Return a legacy_psymtab.
(read_dbx_symtab, start_psymtab, dbx_end_psymtab)
(dbx_psymtab_to_symtab_1, read_ofile_symtab): Use legacy_psymtab.
* ctfread.c (struct ctf_psymtab): New.
(ctf_start_symtab, ctf_end_symtab, psymtab_to_symtab): Take a
ctf_psymtab.
(ctf_psymtab::read_symtab): Rename from ctf_read_symtab.
(create_partial_symtab): Return a ctf_psymtab.
(scan_partial_symbols): Update.

Change-Id: Ia57a828786867d6ad03200af8f996f48ed15285e

Turn start_psymtab_common into a constructor

This turns start_psymtab_common into a constructor, and then changes
the callers to use "new" directly.  This completes the psymtab
allocation transition -- now it is possible for symbol readers to
subclass struct partial_symtab.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_start_psymtab): Use new.
* psymtab.c (partial_symtab::partial_symtab): New constructor,
renamed from start_psymtab_common.
* psympriv.h (struct partial_symtab): Add new constructor.
(start_psymtab_common): Don't declare.
* mdebugread.c (parse_partial_symbols): Use new.
* dwarf2read.c (create_partial_symtab): Use new.
* dbxread.c (start_psymtab): Use new.
* ctfread.c (create_partial_symtab): Use new.

Change-Id: I5a0217bcb52bcfa442559771954bb66bd9ccbf02

Change allocate_psymtab to be a constructor

This is the next step in getting the symbol readers to allocate
psymtabs themselves: change allocate_psymtab to be an ordinary
constructor, and then use "new" at the previous call sites.  Note that
this doesn't get us all the way -- start_psymtab_common is still
allocating a partial symtab.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_end_psymtab): Use new.
* psymtab.c (start_psymtab_common): Use new.
(partial_symtab::partial_symtab): Rename from allocate_psymtab.
Update.
* psympriv.h (struct partial_symtab): Add parameters to
constructor.  Don't inline.
(allocate_psymtab): Don't declare.
* mdebugread.c (new_psymtab): Use new.
* dwarf2read.c (dwarf2_create_include_psymtab): Use new.
* dbxread.c (dbx_end_psymtab): Use new.

Change-Id: Iffeae64c925050b90b9916cbc36e15b26ff42226

Do not allocate psymtabs via psymtab_storage

Currently, partial symbol tables are allocated by a method in
psymtab_storage.  However, eventually we want to subclass partial
symtabs in the symbol readers, so the calls to "new" will have to
happen there.  This patch is a first step, moving the allocation from
psymtab_storage and into allocate_psymtab.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* psymtab.h (class psymtab_storage) <install_psymtab>: Rename from
allocate_psymtab.  Update documentation.
* psymtab.c (psymtab_storage::install_psymtab): Rename from
allocate_psymtab.  Do not use new.
(allocate_psymtab): Use new.  Update.

Change-Id: Iba6a9bf3ee1e78062fdb9f007c3010f826f64bc8

Change some psymtab fields to bool

This changes a few fields in partial_symtab to have type bool.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* xcoffread.c (xcoff_psymtab_to_symtab_1): Update.
* psymtab.c (psym_print_stats): Update.
* psympriv.h (struct partial_symtab) <readin,
psymtabs_addrmap_supported, anonymous>: Now bool.
* mdebugread.c (psymtab_to_symtab_1): Update.
* dwarf2read.c (create_type_unit_group, create_partial_symtab)
(build_type_psymtabs_reader, psymtab_to_symtab_1)
(process_full_comp_unit, process_full_type_unit): Update.
* dbxread.c (dbx_psymtab_to_symtab_1): Update.
* ctfread.c (psymtab_to_symtab): Update.

Change-Id: I206761d083493589049ea0bc785ed6542339234d

Use new and delete for psymtabs

This changes psymtabs to be allocated with new and destroyed with
delete.  As a consequence, the psymtab free-list is also removed.

The motivation for this is to let symbol readers subclass
partial_symtab.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* mdebugread.c (parse_partial_symbols): Use discard_psymtab.
* psymtab.h (class psymtab_storage) <free_psymtabs>: Remove.
* psymtab.c (psymtab_storage): Delete psymtabs.
(psymtab_storage::allocate_psymtab): Use new.
(psymtab_storage::discard_psymtab): Use delete.
* psympriv.h (struct partial_symtab): Add constructor and
initializers.

Change-Id: I4e78ac538fc0ea52b57489c1afb8f935a30941ef

Remove an include from machoread.c

machoread.c does not need to include psympriv.h.

gdb/ChangeLog
2020-01-26  Tom Tromey  <tom@tromey.com>

* machoread.c: Do not include psympriv.h.

Change-Id: I6362bd2e95e7416cb9bae3d48b69dd6dbe4f2cc8

Document m68k floating point feature correspondence

From what I can tell, The m68k floating point target feature should
apparently always be called "org.gnu.gdb.coldfire.fp" -- even when the
primary feature is not "coldfire", because m68k_gdbarch_init only
checks for this feature when assigning register numbers.

However, the floating point registers are expected to match what gdb
thinks are the register sizes for the primary feature.  For example,
if the main feature is "coldfire", then the floating point registers
should be 64 bits.

See this note for some an instance of this confusion:

    https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg04564.html

This patch documents the oddity.

Let me know what you think.  An alternate approach here might be to
make gdb adapt to the register sizes as actually reported.  I'm not
sure if this makes sense or not.

gdb/doc/ChangeLog
2020-01-26  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (M68K Features): Document floating-point feature
correspondence.

Change-Id: I4cd86acbe3449a29ce38327524c508c206b25b8f

Automatic date update in version.in

Document 'set|show exec-file-mismatch (ask|warn|off)'

Mention in NEWS the new option and the set/show commands.

Document in gdb.texinfo the new option and the set/show commands.

gdb/ChangeLog
2020-01-25  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* NEWS: Mention the new option and the set/show commands.

gdb/doc/ChangeLog
2020-01-25  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.texinfo (Attach): Document the new option and the
set/show commands.
(Connecting): Reference the exec-file-mismatch option.

Test 'set exec-file-mismatch ask|warn|off'.

Modify gdb.base/attach.exp to test the behaviour of the option
exec-file-mismatch.  Note that this test can also be run using/
  make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS=gdb.base/attach.exp

to test the behaviour of attaching to running program using a gdb server.

Note: when running the test with a gdbserver, the tests in
test_command_line_attach_run fail because the command "run" is not supported.
I tried to extend the condition
    if ![isnative] then {
unsupported "commandline attach run test"
return 0
    }
but unclear to me how to best do that.  The below trials all failed
to work properly:
    if { ![isnative] || [target_is_gdbserver] } then {
    if { ![isnative] || [use_gdb_stub] } then {
    if { ![isnative] || [is_remote target] } then {
  => could never obtain a condition that was true with gdbserver.

2020-01-25  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.base/attach.exp: Test 'set exec-file-mismatch'.

Implement 'set/show exec-file-mismatch'.

This option allows to tell GDB to detect and possibly handle mismatched exec-files.

A recurrent problem with GDB is that GDB uses the wrong exec-file
when using the attach/detach commands successively.
Also, in case the user specifies a file on the command line but attaches
to the wrong PID, this error is not made visible and gives a not user
understandable behaviour.

For example:
  $ gdb
  ...
  (gdb) atta 2682  ############################################  PID running 'sleepers' executable
  Attaching to process 2682
  [New LWP 2683]
  [New LWP 2684]
  [New LWP 2685]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
  84    ../sysdeps/unix/syscall-template.S: No such file or directory.
  (gdb) det
  Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
  [Inferior 1 (process 2682) detached]
  (gdb) atta 31069 ############################################  PID running 'gdb' executable
  Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
  0x00007f43c23478a0 in ?? ()
  (gdb) bt
  #0  0x00007f43c23478a0 in ?? ()
  #1  0x0000558909e3ad91 in ?? ()
  #2  0x0000202962646700 in ?? ()
  #3  0x00007ffc69c74e70 in ?? ()
  #4  0x000055890c1d2350 in ?? ()
  #5  0x0000000000000000 in ?? ()
  (gdb)

The second attach has kept the executable of the first attach.
(in this case, 31069 is the PID of a GDB, that has nothing to do
with the first determined 'sleepers' executable).

Similarly, if specifying an executable, but attaching to a wrong pid,
we get:

  gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
  ...
  Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
  (gdb) atta 31069 ############################################  PID running 'gdb' executable
  Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
  0x00007f43c23478a0 in ?? ()
  (gdb) bt
  #0  0x00007f43c23478a0 in ?? ()
  #1  0x0000558909e3ad91 in ?? ()
  #2  0x0000202962646700 in ?? ()
  #3  0x00007ffc69c74e70 in ?? ()
  #4  0x000055890c1d2350 in ?? ()
  #5  0x0000000000000000 in ?? ()
  (gdb)

And it is unclear to the user what has happened/what is going wrong.

This patch series implements a new option:
    (gdb) apropos exec-file-mismatch
    set exec-file-mismatch -- Set exec-file-mismatch handling (ask|warn|off).
    show exec-file-mismatch -- Show exec-file-mismatch handling (ask|warn|off).
    (gdb) help set exec-file-mismatch
    Set exec-file-mismatch handling (ask|warn|off).
    Specifies how to handle a mismatch between the current exec-file name
    loaded by GDB and the exec-file name automatically determined when attaching
    to a process:

     ask  - warn the user and ask whether to load the determined exec-file.
     warn - warn the user, but do not change the exec-file.
     off  - do not check for mismatch.

"ask" means: in case of mismatch between the current exec-file name
and the automatically determined exec-file name of the PID we are attaching to,
give a warning to the user and ask whether to load the automatically determined
exec-file.

"warn" means: in case of mismatch, just give a warning to the user.

"off" means: do not check for mismatch.

This fixes PR gdb/17626.
There was a previous trial to fix this PR.
See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html
This trial was however only fixing the problem for the automatically
determined executable files when doing attach.
It was differentiating the 'user specified executable files' ("sticky")
from the executable files automatically found by GDB.
But such user specified sticky executables are in most cases due
to a wrong manipulation by the user, giving unexpected results
such as backtrace showing no function like in the above example.

This patch ensures that whenever a process executable can be
determined, that the user is warned if there is a mismatch.

The same tests as above then give:

  (gdb) atta 2682
  Attaching to process 2682
  [New LWP 2683]
  [New LWP 2684]
  [New LWP 2685]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
  84    ../sysdeps/unix/syscall-template.S: No such file or directory.
  (gdb) det
  Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
  [Inferior 1 (process 2682) detached]
  (gdb) atta 31069
  Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
  warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
  and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
  exec-file-mismatch handling is currently "ask"
  Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
  Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
  Setting up the environment for debugging gdb.
  ...
  Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
  0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
  84    ../sysdeps/unix/syscall-template.S: No such file or directory.
  (top-gdb) bt
  During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f43c23478ad
  During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
  During symbol reading: cannot get low and high bounds for subprogram DIE at 0x12282a7
  During symbol reading: Child DIE 0x12288ba and its abstract origin 0x1228b26 have different parents
  During symbol reading: DW_AT_call_target target DIE has invalid low pc, for referencing DIE 0x1229540 [in module /bd/home/philippe/gdb/git/build_fixes/gdb/gdb]
  #0  0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
  #1  0x0000558909e3ad91 in poll (__timeout=-1, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
  #2  gdb_wait_for_event (block=block@entry=1) at ../../fixes/gdb/event-loop.c:772
  #3  0x0000558909e3aef4 in gdb_do_one_event () at ../../fixes/gdb/event-loop.c:347
  #4  0x0000558909e3b085 in gdb_do_one_event () at ../../fixes/gdb/common/common-exceptions.h:219
  #5  start_event_loop () at ../../fixes/gdb/event-loop.c:371
  During symbol reading: Member function "~_Sp_counted_base" (offset 0x1c69bf7) is virtual but the vtable offset is not specified
  During symbol reading: Multiple children of DIE 0x1c8f5a0 refer to DIE 0x1c8f0ee as their abstract origin
  #6  0x0000558909ed3b78 in captured_command_loop () at ../../fixes/gdb/main.c:331
  #7  0x0000558909ed4b6d in captured_main (data=<optimized out>) at ../../fixes/gdb/main.c:1174
  #8  gdb_main (args=<optimized out>) at ../../fixes/gdb/main.c:1190
  #9  0x0000558909c1e9a8 in main (argc=<optimized out>, argv=<optimized out>) at ../../fixes/gdb/gdb.c:32
  (top-gdb)

  gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
  ...
  Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
  (gdb) atta 31069
  Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
  warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
  and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
  exec-file-mismatch handling is currently "ask"
  Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
  Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
  Setting up the environment for debugging gdb.
  ....

In other words, it now works as intuitively expected by the user.
If ever the user gave the correct executable on the command line,
then attached to the wrong pid, then confirmed loading the wrong executable,
the user can simply fix this by detaching, and attaching to the correct pid,
GDB will then tell again to the user that the exec-file might better
be loaded.

The default value of "ask" is chosen instead of e.g. "warn" as in most
cases, switching of executable will be the correct action,
and in any case, the user can decide to not load the executable,
as GDB asks a confirmation to the user to load the new executable.

For settings "ask" and "warn", the new function validate_exec_file ()
tries to get the inferior pid exec file and compares it with the current
exec file.  In case of mismatch, it warns the user and optionally load
the executable.
This function is called in the attach_command implementation to cover
most cases of attaching to a running process.
It must also be called in remote.c, as the attach command is not supported
for all types of remote gdbserver.

gdb/ChangeLog
2020-01-25  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* exec.c (exec_file_mismatch_names, exec_file_mismatch_mode)
(show_exec_file_mismatch_command, set_exec_file_mismatch_command)
(validate_exec_file): New variables, enums, functions.
(exec_file_locate_attach, print_section_info): Style the filenames.
(_initialize_exec): Install show_exec_file_mismatch_command and
 set_exec_file_mismatch_command.
* gdbcore.h (validate_exec_file): Declare.
* infcmd.c (attach_command): Call validate_exec_file.
* remote.c ( remote_target::remote_add_inferior): Likewise.

Automatic date update in version.in

gdb: Better frame tracking for inline frames

This commit improves GDB's handling of inline functions when there are
more than one inline function in a stack, so for example if we have a
stack like:

   main -> aaa -> bbb -> ccc -> ddd

And aaa, bbb, and ccc are all inline within main GDB should (when
given sufficient debug information) be able to step from main through
aaa, bbb, and ccc.  Unfortunately, this currently doesn't work, here's
an example session:

  (gdb) start
  Temporary breakpoint 1 at 0x4003b0: file test.c, line 38.
  Starting program: /project/gdb/tests/inline/test

  Temporary breakpoint 1, main () at test.c:38
  38   global_var = 0;
  (gdb) step
  39   return aaa () + 1;
  (gdb) step
  aaa () at test.c:39
  39   return aaa () + 1;
  (gdb) step
  bbb () at test.c:39
  39   return aaa () + 1;
  (gdb) step
  ccc () at test.c:39
  39   return aaa () + 1;
  (gdb) step
  ddd () at test.c:32
  32   return global_var;
  (gdb) bt
  #0  ddd () at test.c:32
  #1  0x00000000004003c1 in ccc () at test.c:39
  #2  bbb () at test.c:26
  #3  aaa () at test.c:14
  #4  main () at test.c:39

Notice that once we get to line 39 in main, GDB keeps reporting line
39 in main as the location despite understanding that the inferior is
stepping through the nested inline functions with each use of step.

The problem is that as soon as the inferior stops we call
skip_inline_frames (from inline-frame.c) which calculates the
inferiors current state in relation to inline functions - it figures
out if we're in an inline function, and if we are counts how many
inline frames there are at the current location.

So, in our example above, when we step from line 38 in main to line 39
we stop at a location that is simultaneously in all of main, aaa, bbb,
and ccc.  The block structure reflects the order in which the
functions would be called, with ccc being the most inner block and
main being the most outer block.  When we stop GDB naturally finds the
block for ccc, however within skip_inline_frames we spot that bbb,
aaa, and main are super-blocks of the current location and that each
layer represents an inline function.  The skip_inline_frames then
records the depth of inline functions (3 in this case for aaa, bbb,
and ccc) and also the symbol of the outermost inline function (in this
case 'aaa' as main isn't an inline function, it just has things inline
within it).

Now GDB understands the stack to be main -> aaa -> bbb -> ccc,
however, the state initialised in skip_inline_frames starts off
indicating that we should hide 3 frames from the user, so we report
that we're in main at line 39.  The location of main, line 39 is
derived by asking the inline function state for the last symbol in the
stack (aaa in this case), and then asking for it's location - the
location of an inlined function symbol is its call site, so main, line
39 in this case.

If the user then asks GDB to step we don't actually move the inferior
at all, instead we spot that we are in an inline function stack,
lookup the inline state data, and reduce the skip depth by 1.  We then
report to the user that GDB has stopped.  GDB now understands that we
are in 'aaa'.  In order to get the precise location we again ask GDB
for the last symbol from the inline data structure, and we are again
told 'aaa', we then get the location from 'aaa', and report that we
are in main, line 39.

Hopefully it's clear what the mistake here is, once we've reduced the
inline skip depth we should not be using 'aaa' to compute the precise
location, instead we should be using 'bbb'.  That is what this patch
does.

Now, when we call skip_inline_frames instead of just recording the
last skipped symbol we now record all symbols in the inline frame
stack.  When we ask GDB for the last skipped symbol we return a symbol
based on how many frames we are skipping, not just the last know
symbol.

With this fix in place, the same session as above now looks much
better:

  (gdb) start
  Temporary breakpoint 1 at 0x4003b0: file test.c, line 38.
  Starting program: /project/gdb/tests/inline/test

  Temporary breakpoint 1, main () at test.c:38
  38   global_var = 0;
  (gdb) s
  39   return aaa () + 1;
  (gdb) s
  aaa () at test.c:14
  14   return bbb () + 1;
  (gdb) s
  bbb () at test.c:26
  26   return ccc () + 1;
  (gdb) s
  ccc () at test.c:20
  20   return ddd () + 1;
  (gdb) s
  ddd () at test.c:32
  32   return global_var;
  (gdb) bt
  #0  ddd () at test.c:32
  #1  0x00000000004003c1 in ccc () at test.c:20
  #2  bbb () at test.c:26
  #3  aaa () at test.c:14
  #4  main () at test.c:39

gdb/ChangeLog:

* frame.c (find_frame_sal): Move call to get_next_frame into more
inner scope.
* inline-frame.c (inilne_state) <inline_state>: Update argument
types.
(inilne_state) <skipped_symbol>: Rename to...
(inilne_state) <skipped_symbols>: ...this, and change to a vector.
(skip_inline_frames): Build vector of skipped symbols and use this
to reate the inline_state.
(inline_skipped_symbol): Add a comment and some assertions, fetch
skipped symbol from the list.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/dw2-inline-many-frames.c: New file.
* gdb.dwarf2/dw2-inline-many-frames.exp: New file.

Change-Id: I99def5ffb44eb9e58cda4b449bf3d91ab0386c62

gdb: Don't reorder line table entries too much when sorting.

Don't reorder line table entries for the same address when sorting the
line table, maintain the compiler given line order.  Usually this will
reflect the order in which lines are conceptually encountered at a
given address.

Consider this example:

/* 1  */    volatile int global_var;
/* 2  */    int  __attribute__ ((noinline))
/* 3  */    bar ()
/* 4  */    {
/* 5  */      return global_var;
/* 6  */    }
/* 7  */    static inline int __attribute__ ((always_inline))
/* 8  */    foo ()
/* 9  */    {
/* 10 */      return bar ();
/* 11 */    }
/* 12 */    int
/* 13 */    main ()
/* 14 */    {
/* 15 */      global_var = 0;
/* 16 */      return foo ();
/* 17 */    }

GCC 10 currently generates a line table like this (as shown by
objdump):

  CU: ./test.c:
  File name          Line number    Starting address
  test.c                       4            0x4004b0
  test.c                       5            0x4004b0
  test.c                       6            0x4004b6
  test.c                       6            0x4004b7

  test.c                      14            0x4003b0
  test.c                      15            0x4003b0
  test.c                      16            0x4003ba
  test.c                      10            0x4003ba
  test.c                      10            0x4003c1

The interesting entries are those for lines 16 and 10 at address
0x4003ba, these represent the call to foo and the inlined body of
foo.

With the current line table sorting GDB builds the line table like
this (as shown by 'maintenance info line-table'):

  INDEX    LINE ADDRESS
  0          14 0x00000000004003b0
  1          15 0x00000000004003b0
  2          10 0x00000000004003ba
  3          16 0x00000000004003ba
  4         END 0x00000000004003c1
  5           4 0x00000000004004b0
  6           5 0x00000000004004b0
  7         END 0x00000000004004b7

Notice that entries 2 and 3 for lines 10 and 16 are now in a different
order to the line table as given by the compiler.  With this patch
applied the order is now:

  INDEX    LINE ADDRESS
  0          14 0x00000000004003b0
  1          15 0x00000000004003b0
  2          16 0x00000000004003ba
  3          10 0x00000000004003ba
  4         END 0x00000000004003c1
  5           4 0x00000000004004b0
  6           5 0x00000000004004b0
  7         END 0x00000000004004b7

Notice that entries 2 and 3 are now in their original order again.

The consequence of the incorrect ordering is that when stepping
through inlined functions GDB will display the wrong line for the
inner most frame.  Here's a GDB session before this patch is applied:

  Starting program: /home/andrew/tmp/inline/test

  Temporary breakpoint 1, main () at test.c:15
  15 /* 15 */      global_var = 0;
  (gdb) step
  16 /* 16 */      return foo ();
  (gdb) step
  foo () at test.c:16
  16 /* 16 */      return foo ();
  (gdb) step
  bar () at test.c:5
  5 /* 5  */      return global_var;

The step from line 15 to 16 was fine, but the next step should have
taken us to line 10, instead we are left at line 16.  The final step
to line 5 is as expected.

With this patch applied the session goes better:

  Starting program: /home/andrew/tmp/inline/test

  Temporary breakpoint 1, main () at test.c:15
  15 /* 15 */      global_var = 0;
  (gdb) step
  16 /* 16 */      return foo ();
  (gdb) step
  foo () at test.c:10
  10 /* 10 */      return bar ();
  (gdb) step
  bar () at test.c:5
  5 /* 5  */      return global_var;

We now visit the lines as 15, 16, 10, 5 as we would like.

The reason for this issue is that the inline frame unwinder is
detecting that foo is inlined in main.  When we stop at the shared
address 0x4003ba the inline frame unwinder first shows us the outer
frame, this information is extracted from the DWARF's
DW_TAG_inlined_subroutine entries and passed via GDB's block data.

When we step again the inlined frame unwinder moves us up the call
stack to the inner most frame at which point the frame is displayed as
normal, with the location for the address being looked up in the line
table.

As GDB uses the last line table entry for an address as "the" line to
report for that address it is critical that GDB maintain the order of
the line table entries.  In the first case, by reordering the line
table we report the wrong location.

I had to make a small adjustment in find_pc_sect_line in order to
correctly find the previous line in the line table.  In some line
tables I was seeing an actual line entry and an end of sequence marker
at the same address, before this commit these would reorder to move
the end of sequence marker before the line entry (end of sequence has
line number 0).  Now the end of sequence marker remains in its correct
location, and in order to find a previous line we should step backward
over any end of sequence markers.

As an example, the binary:
  gdb/testsuite/outputs/gdb.dwarf2/dw2-ranges-func/dw2-ranges-func-lo-cold

Has this line table before the patch:

  INDEX    LINE ADDRESS
  0          48 0x0000000000400487
  1         END 0x000000000040048e
  2          52 0x000000000040048e
  3          54 0x0000000000400492
  4          56 0x0000000000400497
  5         END 0x000000000040049a
  6          62 0x000000000040049a
  7         END 0x00000000004004a1
  8          66 0x00000000004004a1
  9          68 0x00000000004004a5
  10         70 0x00000000004004aa
  11         72 0x00000000004004b9
  12        END 0x00000000004004bc
  13         76 0x00000000004004bc
  14         78 0x00000000004004c0
  15         80 0x00000000004004c5
  16        END 0x00000000004004cc

And after this patch:

  INDEX    LINE ADDRESS
  0          48 0x0000000000400487
  1          52 0x000000000040048e
  2         END 0x000000000040048e
  3          54 0x0000000000400492
  4          56 0x0000000000400497
  5         END 0x000000000040049a
  6          62 0x000000000040049a
  7          66 0x00000000004004a1
  8         END 0x00000000004004a1
  9          68 0x00000000004004a5
  10         70 0x00000000004004aa
  11         72 0x00000000004004b9
  12        END 0x00000000004004bc
  13         76 0x00000000004004bc
  14         78 0x00000000004004c0
  15         80 0x00000000004004c5
  16        END 0x00000000004004cc

When calling find_pc_sect_line with the address 0x000000000040048e, in
both cases we find entry #3, we then try to find the previous entry,
which originally found this entry '2         52 0x000000000040048e',
after the patch it finds '2         END 0x000000000040048e', which
cases the lookup to fail.

By skipping the END marker after this patch we get back to the correct
entry, which is now #1: '1          52 0x000000000040048e', and
everything works again.

gdb/ChangeLog:

* buildsym.c (lte_is_less_than): Delete.
(buildsym_compunit::end_symtab_with_blockvector): Create local
lambda function to sort line table entries, and use
std::stable_sort instead of std::sort.
* symtab.c (find_pc_sect_line): Skip backward over end of sequence
markers when looking for a previous line.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/dw2-inline-stepping.c: New file.
* gdb.dwarf2/dw2-inline-stepping.exp: New file.

Change-Id: Ia0309494be4cfd9dcc554f30209477f5f040b21b

gdb: Include end of sequence markers in the line table

In this commit:

  commit d9b3de22f33e400f7f409cce3acf6c7dab07dd79
  Date:   Wed May 27 14:44:29 2015 -0700

      Add struct to record dwarf line number state machine.

I believe an unintended change was made to how we store the DWARF line
table, the end of sequence markers between sequences of lines were
lost from the line table.

This commit fixes this small oversight and restores the end of
sequence markers.

Given that we've survived this long without noticing is clearly an
indication that this isn't that serious, however, a later patch that I
am developing would benefit from having the markers in place, so I'd
like to restore them.

Having the markers also means that the output of 'maintenance info
line-table' now more closely reflects the DWARF line table.

I've taken this opportunity to improve how 'maintenance info
line-table' displays the end of sequence markers - it now uses the END
keyword, rather than just printing an entry with line number 0.  So we
see this:

  INDEX    LINE ADDRESS
  0          12 0x00000000004003b0
  1          17 0x00000000004003b0
  2          18 0x00000000004003b0
  3         END 0x00000000004003b7
  4           5 0x00000000004004a0
  5           6 0x00000000004004a0
  6         END 0x00000000004004a7

Instead of what we would have seen, which was this:

  INDEX    LINE ADDRESS
  0          12 0x00000000004003b0
  1          17 0x00000000004003b0
  2          18 0x00000000004003b0
  3           0 0x00000000004003b7
  4           5 0x00000000004004a0
  5           6 0x00000000004004a0
  6           0 0x00000000004004a7

I've added a small test that uses 'maintenance info line-table' to
ensure that we don't regress this again.

gdb/ChangeLog:

* dwarf2read.c (lnp_state_machine::record_line): Include
end_sequence parameter in debug print out.  Record the line if we
are at an end_sequence marker even if it's not the start of a
statement.
* symmisc.c (maintenance_print_one_line_table): Print end of
sequence markers with 'END' not '0'.

gdb/testsuite/ChangeLog:

* gdb.base/maint.exp: Update line table parsing test.
* gdb.dwarf2/dw2-ranges-base.exp: Add new line table parsing test.

Change-Id: I002f872248db82a1d4fefdc6b51ff5dbf932d8a8

RISC-V: Minor cleanup for s extension support.

Looking at older versions of the patch, I confirmed that the odd comment
I referred to earlier was indeed from the removal of the sx support.  It
also explains an oddly formatted switch statement.  This patch fixes both
minor problems.

bfd/
* elfxx-riscv.c (riscv_get_prefix_class): Format s case like others.
(riscv_parse_prefixed_ext): Fix s extension comment and reword to
avoid over long line.

Change-Id: I1cb62e4a16188270f029b6376e4b1684000d6c7a

Fix re-runs of a second inferior (PR gdb/25410)

This fixes a latent bug exposed by the multi-target patch (5b6d1e4fa
"Multi-target support), and then fixes two other latent bugs exposed
by fixing that first latent bug.

The symptom described in the bug report is that starting a first
inferior, then trying to run a second (multi-threaded) inferior twice,
causes libthread_db to fail to load, along with other erratic
behavior:

 (gdb) run
 Starting program: /tmp/foo
 warning: td_ta_new failed: generic error

Going a bit deeply, I found that if the two inferiors have different
symbols, we can see that just after inferior 2 exits, we are left with
inferior 2 selected, which is correct, but the symbols in scope belong
to inferior 1, which is obviously incorrect...

This problem is that there's a path in
scoped_restore_current_thread::restore() that switches to no thread
selected, and switches the current inferior, but leaves the current
program space as is, resulting in leaving the program space pointing
to the wrong program space (the one of the other inferior).  This was
happening after handling TARGET_WAITKIND_NO_RESUMED, which is an event
that triggers after TARGET_WAITKIND_EXITED for the previous inferior
exit.  Subsequent symbol lookups find the symbols of the wrong
inferior.

The fix is to use switch_to_inferior_no_thread in that problem spot.
This function was recently added along with the multi-target work
exactly for these situations.

As for testing, this patch adds a new testcase that tests symbol
printing just after inferior exit, which exercises the root cause of
the problem more directly.  And then, to cover the use case described
in the bug too, it also exercises the lithread_db.so mis-loading, by
using TLS printing as a proxy for being sure that threaded debugging
was activated sucessfully.  The testcase fails without the fix like
this, for the "print symbol just after exit" bits:

 ...
 [Inferior 1 (process 8719) exited normally]
 (gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: continue until exit
 print re_run_var_1
 No symbol "re_run_var_1" in current context.
 (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: print re_run_var_1
 ...

And like this for the "libthread_db.so loading" bits:

 (gdb) run
 Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run
 warning: td_ta_new failed: generic error
 [New LWP 27001]

 Thread 1.1 "multi-re-run" hit Breakpoint 3, all_started () at /home/pedro/gdb/binutils-gdb/build/../src/gdb/testsuite/gdb.multi/multi-re-run.c:44
 44      }
 (gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: running to all_started in runto
 print tls_var
 Cannot find thread-local storage for LWP 27000, executable file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run:
 Cannot find thread-local variables on this target
 (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: print tls_var

As mentioned, that fix above goes on to expose a couple other latent
bugs.  This commit fixes those as well.

The first latent bug exposed is in
infrun.c:handle_vfork_child_exec_or_exit.  The current code is leaving
inf->pspace == NULL while calling clone_program_space.  The idea was
to make it so that the breakpoints module doesn't use this inferior's
pspace to set breakpoints.  With that, any
scoped_restore_current_thread use from within clone_program_space
tries to restore a NULL program space, which hits an assertion:

 Attaching after Thread 0x7ffff74b8700 (LWP 27276) vfork to child process 27277]
 [New inferior 2 (process 27277)]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib64/libthread_db.so.1".
 /home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:243: internal-error: void set_current_program_space(program_space*): Assertion `pspace != NULL' faile
 d.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.threads/vfork-follow-child-exit.exp: detach-on-fork=off: continue (GDB internal error)

That NULL pspace idea was legitimate, but it's no longer necessary,
since commit b2e586e850db ("Defer breakpoint reset when cloning
progspace for fork child").  So the fix is to just set the inferior's
program space earlier.

The other latent bug exposed is in exec.c.  When exec_close is called
from the program_space destructor, it is purposedly called with a
current program space that is not the current inferior's program
space.  The problem is that the multi-target work added some code to
remove_target_sections that loops over all inferiors, and uses
scoped_restore_current_thread to save/restore the previous
thread/inferior/frame state.  This makes it so that exec_close returns
with the current program space set to the current inferior's program
space, which is exactly what we did not want.  Then the program_space
destructor continues into free_all_objfiles, but it is now running
that method on the wrong program space, resulting in:

 Reading symbols from /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads...
 Reading symbols from /usr/lib/debug/usr/lib64/libpthread-2.26.so.debug...
 Reading symbols from /usr/lib/debug/usr/lib64/libm-2.26.so.debug...
 Reading symbols from /usr/lib/debug/usr/lib64/libc-2.26.so.debug...
 Reading symbols from /usr/lib/debug/usr/lib64/ld-2.26.so.debug...
 [Inferior 3 (process 9583) exited normally]
 /home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:170: internal-error: void program_space::free_all_objfiles(): Assertion `so->objfile == NULL' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited (GDB internal error)

The fix is to use scoped_restore_current_pspace_and_thread instead of
scoped_restore_current_thread.

gdb/ChangeLog:
2020-01-24  Pedro Alves  <palves@redhat.com>

PR gdb/25410
* thread.c (scoped_restore_current_thread::restore): Use
switch_to_inferior_no_thread.
* exec.c: Include "progspace-and-thread.h".
(add_target_sections, remove_target_sections):
scoped_restore_current_pspace_and_thread instead of
scoped_restore_current_thread.
* infrun.c (handle_vfork_child_exec_or_exit): Assign the pspace
and aspace to the inferior before calling clone_program_space.
Remove stale comment.

gdb/testsuite/ChangeLog:
2020-01-24  Pedro Alves  <palves@redhat.com>

PR gdb/25410
* gdb.multi/multi-re-run-1.c: New.
* gdb.multi/multi-re-run-2.c: New.
* gdb.multi/multi-re-run.exp: New.

Add install-strip target to gdbserver

So far this was only possible indirectly when invoked from the gdb directory.
This makes the install-strip target independent from gdb.

2020-01-24  Hannes Domani  <ssbssa@yahoo.de>

* Makefile.in (install-strip): New target.
(install_sh, INSTALL_STRIP_PROGRAM, STRIP): New variables.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* configure.ac: Add AM_PROG_INSTALL_STRIP.

Make the class name in the definition match the declaration

Fixes a compile error because the class is actually called
arm_netbsd_nat_target.

gdb/ChangeLog:

2020-01-24  Christian Biesinger  <cbiesinger@google.com>

* arm-nbsd-nat.c (arm_nbsd_nat_target::fetch_registers): Rename to...
(arm_netbsd_nat_target::fetch_registers): ...this.
(arm_nbsd_nat_target::store_registers): Rename to...
(arm_netbsd_nat_target::store_registers): ...this.

Change-Id: Ibebfab9edeff48f54c32d0745afda1d74d31de92

Define _KERNTYPES in arm-nbsd-nat.c

Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only version I
tested).  types.h does not define register_t by default.

We already use this define elsewhere, notably in bsd-kvm.c.

In file included from ../../gdb/arm-nbsd-nat.c:28:
/usr/include/machine/frame.h:54:2: error: unknown type name 'register_t'; did you mean '__register_t'?
        register_t tf_spsr;
        ^
/usr/include/machine/types.h:77:14: note: '__register_t' declared here
typedef int             __register_t;
                        ^

There are other compile errors that this does not fix.

gdb/ChangeLog:

2020-01-24  Christian Biesinger  <cbiesinger@google.com>

* arm-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.

Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e

Support the NetBSD version of pthread_setname_np

On NetBSD, pthread_setname_np takes a printf-style format string plus
one argument:
https://netbsd.gw.com/cgi-bin/man-cgi?pthread_setname_np++NetBSD-current

This patch makes thread-pool.c handle that.

gdbsupport/ChangeLog:

2020-01-24  Christian Biesinger  <cbiesinger@google.com>

* thread-pool.c (set_thread_name): Add an overload for the NetBSD
version of pthread_setname_np.

Change-Id: I61e664a813eaa7f52b6811b1a43e08ac3082d8ef

Fix an illegal call to free() when copying a PE format file.

PR 25447
* coffgen.c (_bfd_coff_close_and_cleanup): Do not clear the keep
syms and keep strings flags as these may have been set in order to
prevent a bogus call to free.

gdbserver: Make `make TAGS' actually work

Fix a:

make: *** No rule to make target '.../gdb/gdbserver/arch/arm.c', needed by 'TAGS'.  Stop.

error produced by `make TAGS' by making the list of sources processed
match actual file locations and by moving host-specific object files
listed in DEPFILES to nat/ or target/ subdirectories as appropriate so
that the location of the corresponding source file can be mechanically
determined.

gdb/gdbserver/
* Makefile.in (SFILES): Adjust paths to point to real files.
(OBS): Move waitstatus.o to target/waitstatus.o.
(TAGS): Transform paths appropriately.
(%.o): Rename to...
(nat/%.o): ... this pattern rule.
(%.o): Rename to...
(target/%.o): ... this pattern rule.
* configure.srv: Adjust paths throughout to include nat/ prefix
with the revant files.
* configure.ac: Add `nat' and `target' to CONFIG_SRC_SUBDIR.
* configure: Regenerate.