bfd: Fix 64-bit relocation handling for a.out

* aoutx.h (swap_std_reloc_out): Special case 64 bit relocations.
(aout_link_reloc_link_order): Likewise. Make r_length an unsigned.

Updated Serbian translation for the binutils sub-directory, and Swedish translation for the opcodes sub-directory.

Fix the disassmbly of SH instructions which have an unsigned 8-bit immediate operand.

PR 22699
opcodes * sh-opc.h (IMM0_8): Replace with IMM0_8S and IMM0_8U.  Use
IMM0_8S for arithmetic insns and IMM0_8U for logical insns.
* sh-dis.c (print_insn_sh): Change IMM0_8 case to IMM0_8S and add
IMM0_8U case.

gas * config/tc-sh.c (build_Mytes): Change operand type IMM0_8 to
IMM0_8S and add support for IMM0_8U.
* testsuite/gas/sh/sh4a.s: Add test of a logical insn using an
unsigned 8-bit immediate.
* testsuite/gas/sh/sh4a.d: Extended expected disassembly.

Remove restriction on skipping some linker tests because their default image base is too high.

PR 25829
* testsuite/ld-scripts/default-script.exp: Add --image-base=0 to
LDFLAGS for targets *-*-mingw64 x86_64-*-cygwin.
* testsuite/ld-scripts/default-script1.d: No longer have to skip
test for those targets.
* testsuite/ld-scripts/default-script2.d: Likewise.
* testsuite/ld-scripts/default-script3.d: Likewise.
* testsuite/ld-scripts/default-script4.d: Likewise.

[gdb/testsuite] Add xfails for PR gcc/90232

With target board debug-types, we have these FAILs:
...
FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols
FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols
...
due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle
struct decl with DW_AT_signature".

Marks these as XFAILs.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (debug_types): New proc.
* gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232.
* gdb.python/py-symtab.exp: Same.

Fix array pretty formatter

Currently, printing with array pretty formatting makes the output actually
less readable than without:

(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 =   {    {1,
    2,
    3},
      {4,
    5,
    6}}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 =   {[0] =     {[0] = 1,
    [1] = 2,
    [2] = 3},
  [1] =     {[0] = 4,
    [1] = 5,
    [2] = 6}}

These changes now also put the first element and the array end bracket on a new
line, similar to the structure pretty formatter:

(gdb) p -array on -- {{1,2,3},{4,5,6}}
$1 = {
  {
    1,
    2,
    3
  },
  {
    4,
    5,
    6
  }
}
(gdb) p -array on -array-indexes on -- {{1,2,3},{4,5,6}}
$2 = {
  [0] = {
    [0] = 1,
    [1] = 2,
    [2] = 3
  },
  [1] = {
    [0] = 4,
    [1] = 5,
    [2] = 6
  }
}

gdb/ChangeLog:

2020-04-29  Hannes Domani  <ssbssa@yahoo.de>

PR gdb/17320
* ada-valprint.c (val_print_packed_array_elements): Move array
end bracket to new line.
(ada_val_print_string): Remove extra spaces before first array
element.
* c-valprint.c (c_value_print_array): Likewise.
* m2-valprint.c (m2_print_array_contents): Likewise.
(m2_value_print_inner): Likewise.
* p-valprint.c (pascal_value_print_inner): Likewise.
* valprint.c (generic_val_print_array): Likewise.
(value_print_array_elements): Move first array element and array
end bracket to new line.

gdb/testsuite/ChangeLog:

2020-04-29  Hannes Domani  <ssbssa@yahoo.de>

PR gdb/17320
* gdb.base/pretty-array.c: New test.
* gdb.base/pretty-array.exp: New file.

[gdb] Fix range loop index in find_method

With target board debug-types, we have:
...
FAIL: gdb.cp/cpexprs.exp: list policy1::function
...

This is a regression triggered by commit 770479f223e "gdb: Fix toplevel types
with -fdebug-types-section".

However, the FAIL is caused by commit 4dedf84da98 "Change
decode_compound_collector to use std::vector" which changes a VEC_iterate loop
into a range loop:
...
-  for (ix = 0; VEC_iterate (symbolp, sym_classes, ix, sym); ++ix)
+  unsigned int ix = 0;
+  for (const auto &sym : *sym_classes)
...
but fails to ensure that the increment of ix happens every iteration.

Fix this by calculating the index variable at the start of the loop body:
...
  for (const auto &elt : *sym_classes)
    {
      unsigned int ix = &elt - &*sym_classes->begin ();
...

Tested on x86_64-linux, with native and target board debug-types.

gdb/ChangeLog:

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

PR symtab/25889
* linespec.c (find_method): Fix ix calculation.

gdb/testsuite/ChangeLog:

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

PR symtab/25889
* gdb.cp/cpexprs.exp: Adapt for inclusion.
* gdb.cp/cpexprs-debug-types.exp: New file.  Set -fdebug-types-section
and include cpexprs.exp.

Automatic date update in version.in

Add definitions of system calls to catch in native NetBSD targets

All platforms on NetBSD use a shared system call table, so use a
single XML file to describe the system calls available on each NetBSD
platform.

gdb/ChangeLog:

       * syscalls/update-netbsd.sh: New file.
       * syscalls/netbsd.xml: Regenerate.
       * data-directory/Makefile.in: Register `netbsd.xml' in
       `SYSCALLS_FILES'

gdb: fix shellcheck warning in update-freebsd.sh

shellcheck reports:

    In update-freebsd.sh line 72:
    }' $1 >> freebsd.xml.tmp
       ^-- SC2086: Double quote to prevent globbing and word splitting.

    Did you mean:
    }' "$1" >> freebsd.xml.tmp

    For more information:
      https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...

Add double quotes to fix it.

gdb/ChangeLog:

* syscalls/update-freebsd.sh: Add double quotes.

Allow Python commands to be in class_tui

Now that Python code can create TUI windows, it seemed appropriate to
allow Python commands to appear in the "TUI" help class.  This patch
adds this capability.

gdb/ChangeLog
2020-04-28  Tom Tromey  <tom@tromey.com>

* NEWS: Update.
* python/py-cmd.c (gdbpy_initialize_commands): Add COMMAND_TUI.
(cmdpy_init): Allow class_tui.

gdb/doc/ChangeLog
2020-04-28  Tom Tromey  <tom@tromey.com>

* python.texi (Commands In Python): Document gdb.COMMAND_TUI.

Add missing ChangeLog entries

gdb: Fix toplevel types with -fdebug-types-section

When debugging a program compiled with -fdebug-types-section,
only the first top-level type in each file is visible to gdb.

The problem was caused by moving the assignment to list_in_scope
from process_full_comp_unit and process_full_type_unit to
start_symtab.  This was fine for process_full_comp_unit, because
symtabs and comp units are one-to-one.  But there can be many type
units per symtab (one for each type), and we only call start_symtab
for the first one.  This adds the necessary assignments on the paths
where start_symtab is not called.

gdb/Changelog:

2020-04-28 Mark Williams <mark@myosotissp.com>

PR gdb/24480
* dwarf2read.c: Add missing assingments to list_in_scope when
start_symtab was already called.

gdb/testsuite/Changelog:

2020-04-28 Mark Williams <mark@myosotissp.com>

PR gdb/24480
* dw4-toplevel-types.exp: Test for top level types.
* dw4-toplevel-types.cc: Test for top level types.

gdb: use gdb:hash_enum as hash function in offset_map_type

When building with g++ 4.8, we get this error (just an excerpt, because
g++ outputs a very long error message):

      CXX    dwarf2/read.o
    ...
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:14616:31:   required from here
    /usr/include/c++/4.8/bits/hashtable_policy.h:1070:12: error: invalid use of incomplete type ‘struct std::hash<sect_offset>’
         struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,

This is the same problem and fix as in commit f23f598e28ad ("[gdb] Fix
build breaker with gcc 4.8").  Pass an explicit hash function rather
than relying on the default std::hash<sect_offset>.

gdb/ChangeLog:

PR gdb/25881
* dwarf2/read.c (offset_map_type): Use
gdb:hash_enum<sect_offset> as hash function.

Rebase libiberty source with latest changes from gcc.

PR 25876
PR demangler/94797
* cp-demangle.c (cplus_demangle_operators): Add ss <=> operator.
* testsuite/demangle-expected: Add operator<=> test.

Fix typo (thead -> thread)

gdb/stubs/ChangeLog:
2020-04-28  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* ia64vms-stub.c: Fix typo in comment (thead -> thread).

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

* gdb.threads/stop-with-handle.exp: Fix typo in comment
(theads -> threads).

gdbsupport/ChangeLog:
2020-04-28  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb-sigmask.h: Fix typo (pthead_sigmask -> pthread_sigmask).

[gdb/testsuite] Add PR number to KFAIL in gdb.opt/inline-cmds.exp

With test-case gdb.opt/inline-cmds.exp, we have:
...
KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/NNNN)
...

I've filed PR25884 for this failure.

Set the KFAIL PR accordingly.

gdb/testsuite/ChangeLog:

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

* gdb.opt/inline-cmds.exp: Set KFAIL PR.

[gdb/testsuite] Remove KFAIL from gdb.base/info-macros.exp

When running test-case gdb.base/info-macros.exp, we have:
...
(gdb) KFAIL: gdb.base/info-macros.exp: info macros info-macros.c:42 \
  (PRMS: gdb/NNNN)
...

The described failure mode however:
...
set test "info macros info-macros.c:42"

set r1 ".*define DEF_MACROS"
set r2 ".*define ONE"
setup_kfail "gdb/NNNN" *-*-*
gdb_test "$test" "$r1$r2"
...
does not match the actual output, given that both defines are in fact
printed.

The pattern fails to match because it's missing a trailing ".*".

Fix this by removing the KFAIL and adding the missing trailing ".*".

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/info-macros.exp: Remove KFAIL.  Add missing trailing ".*".

[gdb/testsuite] Add PR number in KFAIL in gdb.ada/array_ptr_renaming.exp

When running test-case gdb.ada/array_ptr_renaming.exp we run into:
...
(gdb) print ntp^M
$3 = (3 => 30, 40)^M
(gdb) KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/NNNN)
...

I've opened PR25883 for this failure.  Reference the PR from the KFAIL, such
that we have:
...
KFAIL: gdb.ada/array_ptr_renaming.exp: print ntp (PRMS: gdb/25883)
...

gdb/testsuite/ChangeLog:

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

* gdb.ada/array_ptr_renaming.exp: Add PR number in KFAIL.

[gdb/symtab] Handle struct decl with DW_AT_signature

Consider a test-case with sources 36.c:
...
struct s { int i; };
extern void f (void);
int main (void) {
  struct s a;
  f ();
  return 0;
}
...
and 36b.c:
...
struct s { int j; };
void f (void) {
  struct s b;
}
...
compiled like this:
...
$ gcc 36.c 36b.c -g
...

It contains DWARF like this:
...
 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d8>   DW_AT_name        : 36.c
 <1><f4>: Abbrev Number: 2 (DW_TAG_structure_type)
    <f5>   DW_AT_name        : s
 <2><fe>: Abbrev Number: 3 (DW_TAG_member)
    <ff>   DW_AT_name        : i
 <1><110>: Abbrev Number: 5 (DW_TAG_subprogram)
    <111>   DW_AT_name        : main
 <2><12d>: Abbrev Number: 6 (DW_TAG_variable)
    <12e>   DW_AT_name        : a
    <132>   DW_AT_type        : <0xf4>
 <0><146>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <14c>   DW_AT_name        : 36b.c
 <1><168>: Abbrev Number: 2 (DW_TAG_structure_type)
    <169>   DW_AT_name        : s
 <2><172>: Abbrev Number: 3 (DW_TAG_member)
    <173>   DW_AT_name        : j
 <1><184>: Abbrev Number: 5 (DW_TAG_subprogram)
    <185>   DW_AT_name        : f
 <2><19b>: Abbrev Number: 6 (DW_TAG_variable)
    <19c>   DW_AT_name        : b
    <1a0>   DW_AT_type        : <0x168>
...

And when printing "struct s", we get first a random one (with int j), and then
context-specific ones (with int i in main, and int j in f):
...
$ gdb -batch a.out \
  -ex "ptype struct s" \
  -ex start \
  -ex "ptype struct s" \
  -ex "break f" -ex continue \
  -ex "ptype struct s" \
  | grep "int [ij];"
    int j;
    int i;
    int j;
...
Same for -readnow.

However, if we use -fdebug-types-section:
...
$ gcc 36.c 36b.c -g -fdebug-types-section
...
we get:
...
$ gdb ... | grep "int [ij];"
    int j;
    int i;
    int i;
$ gdb -readnow ... | grep "int [ij];"
    int j;
    int j;
    int j;
...

This is due to the fact that both "struct s" DIEs have been moved to the
.debug_types section:
...
  Compilation Unit @ offset 0x0:
   Signature:     0xfd1462823bb6f7b7
 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
 <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
    <1e>   DW_AT_name        : s
 <2><27>: Abbrev Number: 3 (DW_TAG_member)
    <28>   DW_AT_name        : i
  Compilation Unit @ offset 0x3a:
   Signature:     0x534310fbefba324d
 <0><51>: Abbrev Number: 1 (DW_TAG_type_unit)
 <1><57>: Abbrev Number: 2 (DW_TAG_structure_type)
    <58>   DW_AT_name        : s
 <2><61>: Abbrev Number: 3 (DW_TAG_member)
    <62>   DW_AT_name        : j
...
and there's no longer a "struct s" DIE in the 36.c and
and 36b.c CUs to specify which "struct s" belongs in the CU.  This is gcc
PR90232.

However, using a tentative patch for gcc that adds these DIEs (according to
DWARF standard: If the complete declaration of a type has been placed in a
separate type unit, an incomplete declaration of that type in the compilation
unit may provide the unique 64-bit signature of the type using a
DW_AT_signature attribute):
...
  <0><d2>: Abbrev Number: 5 (DW_TAG_compile_unit)
     <d8>   DW_AT_name        : 36.c
+ <1><f4>: Abbrev Number: 6 (DW_TAG_structure_type)
+    <f5>   DW_AT_name        : s
+    <f7>   DW_AT_signature   : signature: 0xfd1462823bb6f7b7
+    <ff>   DW_AT_declaration : 1
  <0><13c>: Abbrev Number: 5 (DW_TAG_compile_unit)
     <142>   DW_AT_name        : 36b.c
+ <1><15e>: Abbrev Number: 6 (DW_TAG_structure_type)
+    <15f>   DW_AT_name        : s
+    <161>   DW_AT_signature   : signature: 0x534310fbefba324d
+    <169>   DW_AT_declaration : 1
...
still does not help, because they're declarations, so new_symbol is not called
for them in process_structure_scope.

Fix this by calling new_symbol for these decls.

Build and tested on x86_64-linux.

Also tested with target board enabling by default -fdebug-types-section
-gdwarf-4, and with gcc with aforementioned tentative patch.  In this
configuration, the patch reduces number of FAILs from 2888 to 238.

gdb/ChangeLog:

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

* dwarf2/read.c (process_structure_scope): Add symbol for struct decl
with DW_AT_signature.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/main-foo.c: New test.
* gdb.dwarf2/struct-with-sig.exp: New file.

Automatic date update in version.in

alpha-vms: divide by zero

The zero check was on the wrong operand.  And, yes, the second operand
popped is supposed to be divided by the first operand popped.

* vms-alpha.c (_bfd_vms_slurp_etir): Correct divide by zero check.
Emit warning message.

x86: Add i386 PE big-object support

The 64-bit version of binutils got support for the PE COFF BIG OBJ format a
couple of years ago.   The BIG OBJ format is a slightly different COFF format
which extends the size of the number of section field in the header from a
uint16_t to a uint32_t and so greatly increases the number of sections allowed.

However the 32-bit version of bfd never got support for this.  The GHC Haskell
compiler generates a great deal of symbols due to it's use of
-ffunction-sections and -fdata-sections.

This meant that we could not build the 32-bit version of the GHC Compiler for
many releases now as binutils didn't have this support.

This patch adds the support to the 32-bit port of binutils as well and also does
come cleanup in the code.

bfd/ChangeLog:

* coff-i386.c (COFF_WITH_PE_BIGOBJ): New.
* coff-x86_64.c (COFF_WITH_PE_BIGOBJ): New.
* config.bfd (targ_selvecs): Rename x86_64_pe_be_vec
to x86_64_pe_big_vec as it not a big-endian format.
(vec i386_pe_big_vec): New.
* configure.ac: Likewise.
* targets.c: Likewise.
* configure: Regenerate.
* pe-i386.c (TARGET_SYM_BIG, TARGET_NAME_BIG,
COFF_WITH_PE_BIGOBJ): New.
* pe-x86_64.c (TARGET_SYM_BIG, TARGET_NAME_BIG):
New.
(x86_64_pe_be_vec): Moved.

gas/ChangeLog:

* NEWS: Add news entry for big-obj.
* config/tc-i386.c (i386_target_format): Support new format.
* doc/c-i386.texi: Add i386 support.
* testsuite/gas/pe/big-obj.d: Rename test to not be x64 specific.
* testsuite/gas/pe/pe.exp (big-obj): Make test run on i386 as well.

ld/ChangeLog:

* pe-dll.c (pe_detail_list):  Add pe-bigobj-i386.

gdb, gdbserver: remove configure check for fs_base/gs_base in user_regs_struct

I recently stumbled on this code mentioning Linux kernel 2.6.25, and
thought it could be time for some spring cleaning (newer GDBs probably
don't need to supports 12-year old kernels).  I then found that the
"legacy" case is probably broken anyway, which gives an even better
motivation for its removal.

In short, this patch removes the configure checks that check if
user_regs_struct contains the fs_base/gs_base fields and adjusts all
uses of the HAVE_STRUCT_USER_REGS_STRUCT_{FS,GS}_BASE macros.  The
longer explanation/rationale follows.

Apparently, Linux kernels since 2.6.25 (that's from 2008) have been
reliably providing fs_base and gs_base as part of user_regs_struct.
Commit df5d438e33d7 in the Linux kernel [1] seems related.  This means
that we can get these values by reading registers with PTRACE_GETREGS.
Previously, these values were obtained using a separate
PTRACE_ARCH_PRCTL ptrace call.

First, I'm not even sure the configure check was really right in the
first place.

The user_regs_struct used by GDB comes from
/usr/include/x86_64-linux-gnu/sys/user.h (or equivalent on other
distros) and is provided by glibc.  glibc has had the fs_base/gs_base
fields in there for a very long time, at least since this commit from
2001 [2].  The Linux kernel also has its version of user_regs_struct,
which I think was exported to user-space at some point.  It included the
fs_base/gs_base fields since at least this 2002 commit [3].  In any
case, my conclusion is that the fields were there long before the
aforementioned Linux kernel commit.  The kernel commit didn't add these
fields, it only made sure that they have reliable values when obtained
with PTRACE_GETREGS.

So, checking for the presence of the fs_base/gs_base fields in struct
user_regs_struct doesn't sound like a good way of knowing if we can
reliably get the fs_base/gs_base values from PTRACE_GETREGS.  My guess
is that if we were using that strategy on a < 2.6.25 kernel, things
would not work correctly:

- configure would find that the user_regs_struct has the fs_base/gs_base
  fields (which are probided by glibc anyway)
- we would be reading the fs_base/gs_base values using PTRACE_GETREGS,
  for which the kernel would provide unreliable values

Second, I have tried to see how things worked by forcing GDB to not use
fs_base/gs_base from PTRACE_GETREGS (forcing it to use the "legacy"
code, by configuring with

  ac_cv_member_struct_user_regs_struct_gs_base=no ac_cv_member_struct_user_regs_struct_fs_base=no

Doing so breaks writing registers back to the inferior.  For example,
calling an inferior functions gives an internal error:

    (gdb) p malloc(10)
    /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408: internal-error: invalid i387 regnum 152

The relevant last frames where this error happens are:

    #8  0x0000563123d262fc in internal_error (file=0x563123e93fd8 "/home/smarchi/src/binutils-gdb/gdb/i387-tdep.c", line=1408, fmt=0x563123e94482 "invalid i387 regnum %d") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
    #9  0x0000563123047d0d in i387_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/i387-tdep.c:1408
    #10 0x0000563122c69e8a in amd64_collect_xsave (regcache=0x5631269453f0, regnum=152, xsave=0x7ffd38402a20, gcore=0) at /home/smarchi/src/binutils-gdb/gdb/amd64-tdep.c:3448
    #11 0x0000563122c5e94c in amd64_linux_nat_target::store_registers (this=0x56312515fd10 <the_amd64_linux_nat_target>, regcache=0x5631269453f0, regnum=152) at /home/smarchi/src/binutils-gdb/gdb/amd64-linux-nat.c:335
    #12 0x00005631234c8c80 in target_store_registers (regcache=0x5631269453f0, regno=152) at /home/smarchi/src/binutils-gdb/gdb/target.c:3485
    #13 0x00005631232e8df7 in regcache::raw_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:765
    #14 0x00005631232e8f0c in regcache::cooked_write (this=0x5631269453f0, regnum=152, buf=0x56312759e468 "@\225\372\367\377\177") at /home/smarchi/src/binutils-gdb/gdb/regcache.c:778
    #15 0x00005631232e75ec in regcache::restore (this=0x5631269453f0, src=0x5631275eb130) at /home/smarchi/src/binutils-gdb/gdb/regcache.c:283
    #16 0x0000563123083fc4 in infcall_suspend_state::restore (this=0x5631273ed930, gdbarch=0x56312718cf20, tp=0x5631270bca90, regcache=0x5631269453f0) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9103
    #17 0x0000563123081eed in restore_infcall_suspend_state (inf_state=0x5631273ed930) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:9151

The problem seems to be that amd64_linux_nat_target::store_registers
calls amd64_native_gregset_supplies_p to know whether gregset provides
fs_base.  When !HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE,
amd64_native_gregset_supplies_p returns false.  store_registers
therefore assumes that it must be an "xstate" register.  This is of
course wrong, and that leads to the failed assertion when
i387_collect_xsave doesn't recognize the register.

amd64_linux_nat_target::store_registers could probably be fixed to
handle this case, but I don't think it's worth it, given that it would
only be to support very old kernels.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5d438e33d7fc914ba9b6e0d6b019a8966c5fcc
[2] https://sourceware.org/git/?p=glibc.git;a=commit;h=c9cf6ddeebb7bb
[3] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=88e4bc32686ebd0b1111a94f93eba2d334241f68

gdb/ChangeLog:

* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* amd64-nat.c (amd64_native_gregset_reg_offset): Adjust.
* amd64-linux-nat.c (amd64_linux_nat_target::fetch_registers,
amd64_linux_nat_target::store_registers, ps_get_thread_area, ): Adjust.

gdbserver/ChangeLog:

* configure.ac: Remove check for fs_base/gs_base in
user_regs_struct.
* configure: Re-generate.
* config.in: Re-generate.
* linux-x86-low.cc (x86_64_regmap, x86_fill_gregset,
x86_store_gregset): Adjust.

Expand dynamic type documentation

This expands the Python dynamic type documentation, as suggested by
Christian.

gdb/doc/ChangeLog
2020-04-27  Tom Tromey  <tromey@adacore.com>

* python.texi (Types In Python): Mention missing fields.  Add
dynamic type example.

gdbsupport: include cstdlib in common-defs.h

In PR 25731 [1], the following build failure was reported:

    ../../binutils-gdb/gdb/gdbtypes.c:1254:10: error: no member named 'abs' in namespace 'std'; did you mean simply 'abs'?
                = ((std::abs (stride) * element_count) + 7) / 8;
                    ^~~~~~~~
                    abs
    /usr/include/stdlib.h:129:6: note: 'abs' declared here
    int      abs(int) __pure2;
             ^
The original report was using:

    $ gcc -v
    Apple LLVM version 8.0.0 (clang-800.0.42.1)
    Target: x86_64-apple-darwin15.6.0

Note that I was _not_ able to reproduce using:

    $ g++ --version
    Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
    Apple clang version 11.0.0 (clang-1100.0.33.17)
    Target: x86_64-apple-darwin19.3.0

The proposed fix is to include <cstdlib> in addition to <stdlib.h>.

Here's an excerpt of [2] relevant to this problem:

    These headers [speaking of the .h form] are allowed to also declare
    the same names in the std namespace, and the corresponding cxxx
    headers are allowed to also declare the same names in the global
    namespace: including <cstdlib> definitely provides std::malloc and
    may also provide ::malloc.  Including <stdlib.h> definitely provides
    ::malloc and may also provide std::malloc

Since we use std::abs, we should not assume that our include of stdlib.h
declares an `abs` function in the `std` namespace.

If we replace the include of stdlib.h with cstdlib, then we fall in the
opposite situation.  A standard C++ library may decide to only put the
declarations in the std namespace, requiring us to prefix all standard
functions with `std::`.  I'm not against that, but for the moment I think the
safest way forward is to just include both.

Note that I don't know what effect this patch can have on any stdlib.h fix
provided by gnulib.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25731
[2] https://en.cppreference.com/w/cpp/header#C_compatibility_headers

gdbsupport/ChangeLog:

* common-defs.h: Include cstdlib.h.

Fix remaining inline/tailcall unwinding breakage for x86_64

Commit 5939967b355ba6a940887d19847b7893a4506067 fixed inline
frame unwinding breakage for some targets (aarch64, riscv, s390...)
but regressed a few amd64 testcases related to tailcalls.

Given the following example situation...

Frame #-1 - sentinel frame
Frame # 0 - inline frame
Frame # 1 - normal frame

... suppose we're at level #1 and call into dwarf2_tailcall_sniffer_first.

We'll attempt to fetch PC, which used to be done via the gdbarch_unwind_pc call
(before 5939967b355ba6a940887d19847b7893a4506067), but now it is being handled
by the get_frame_register function.

gdbarch_unwind_pc will attempt to use frame #1's cache to retrieve information
about the PC. Here's where different architectures behave differently.

x86_64 will find a dwarf rule to retrieve PC from memory, at a CFA + offset
location. So the PC value is readily available and there is no need to
create a lazy value.

For aarch64 (and others), GCC doesn't emit an explicit location for PC, so we
eventually will find that PC is DWARF2_FRAME_REG_UNSPECIFIED. This is known
and is handled by GDB by assuming GCC really meant DWARF2_FRAME_REG_SAME_VALUE.

This means we'll attempt to fetch the register value from frame #0, via a call
to frame_unwind_got_register, which will trigger the creation of a lazy value
that requires a valid frame id for frame #0.

We don't have a valid id for frame #0 yet, so we assert.

Given the above, the following patch attempts to handle the situation without
being too hacky. We verify if the next frame is an inline frame and if its
frame id has been computed already. If it hasn't been computed yet, then we
use the safer get_frame_register function, otherwise we use the regular
gdbarch_unwind_pc hook.

gdb/ChangeLog:

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

* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Handle
problematic inline frame unwinding situation.
* frame.c (frame_id_computed_p): New function.
* frame.h (frame_id_computed_p): New prototype.

GAS: Allow automatically assigned entries in the file table to be reassigned if the source file specifically requests to use the assigned slot.

PR 25878
* dwarf2dbg.c (struct file_entry): Add auto_assigned field.
(assign_file_to_slot): New function.  Fills in an entry in the
files table.
(allocate_filenum): Use new function.
(allocate_filename_to_slot): Use new function.  If the specified
slot entry is already in use, but was chosen automatically then
reassign the automatic entry.

Automatic date update in version.in

Remove class_pseudo

The class_pseudo constant is unused, so this removes it.
Tested by rebuilding.

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

* command.h (enum command_class) <class_pseudo>: Remove.

readelf: NULL dereference

This fixes another missing error check.

* readelf.c (get_num_dynamic_syms): Check DT_MIPS_XHASH was
read before dereferencing, and gracefully return.  Remove
gnu_hash_error variable.  Free gnu hash arrays if number of
syms found is zero.

Fix comments and whitespace in lookup_cmd_composition

2020-04-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* cli/cli-decode.c (lookup_cmd_composition): Fix comments
and whitespace.

Improve -mlfence-after-load

  1.Implict load for POP/POPF/POPA/XLATB, no load for Anysize insns
  2. Add -mlfence-before-ret=shl/yes, adjust operand size of
  or/not/shl according to ret's.
  3. Issue warning for REP CMPS/SCAS since they would affect control
  flow behavior.
  4. Adjust testcases and documents.

gas/Changelog:
* config/tc-i386.c (lfence_before_ret_shl): New member.
(load_insn_p): implict load for POP/POPA/POPF/XLATB, no load
for Anysize insns.
(insert_after_load): Issue warning for REP CMPS/SCAS.
(insert_before_before): Handle iret, Handle
-mlfence-before-ret=shl, Adjust operand size of or/not/shl to ret's,
(md_parse_option): Change -mlfence-before-ret=[none|not|or] to
-mlfence-before-ret=[none/not/or/shl/yes].
Enable -mlfence-before-ret=shl when
-mlfence-beofre-indirect-branch=all and no explict -mlfence-before-ret option.
(md_show_usage): Ditto.
* doc/c-i386.texi: Ditto.
* testsuite/gas/i386/i386.exp: Add new testcases.
* testsuite/gas/i386/lfence-load-b.d: New.
* testsuite/gas/i386/lfence-load-b.e: New.
* testsuite/gas/i386/lfence-load.d: Modified.
* testsuite/gas/i386/lfence-load.e: New.
* testsuite/gas/i386/lfence-load.s: Modified.
* testsuite/gas/i386/lfence-ret-a.d: Modified.
* testsuite/gas/i386/lfence-ret-b.d: Modified.
* testsuite/gas/i386/lfence-ret-c.d: New.
* testsuite/gas/i386/lfence-ret-d.d: New.
* testsuite/gas/i386/lfence-ret.s: Modified.
* testsuite/gas/i386/x86-64-lfence-load-b.d: New.
* testsuite/gas/i386/x86-64-lfence-load.d: Modified.
* testsuite/gas/i386/x86-64-lfence-load.s: Modified.
* testsuite/gas/i386/x86-64-lfence-ret-a.d: Modified.
* testsuite/gas/i386/x86-64-lfence-ret-b.d: Modified.
* testsuite/gas/i386/x86-64-lfence-ret-c.d: New.
* testsuite/gas/i386/x86-64-lfence-ret-d.d: New
* testsuite/gas/i386/x86-64-lfence-ret-e.d: New.
* testsuite/gas/i386/x86-64-lfence-ret.e: New.
* testsuite/gas/i386/x86-64-lfence-ret.s: New.

Automatic date update in version.in

Remove unused code block in inf_ptrace_target::wait

Remove unused PT_GET_PROCESS_STATE block. It used to be used
by OpenBSD, but it is now reimplemented independently in
obsd-nat.c.

gdb/ChangeLog:

       * inf-ptrace.c (inf_ptrace_target::wait): Remove
       `PT_GET_PROCESS_STATE' block.

Change-Id: I9b872df8517b658c0dfe889fc1e4a7009bc5c076

[gdb/testsuite] Add target board debug-types

This patch adds a target board debug-types that switches on
-fdebug-types-section by default.

This -fdebug-types-section option is a gcc option that enables the generation
of a .debug_types section, which is only effective for DWARF version 4.

There are two other boards that enable this: dwarf4-gdb-index and fisson, but
while those test some meaningful combination of options, this board is
intended to test only -fdebug-types-section.

Current results with gcc 7.5.0 are:
...
 === gdb Summary ===

 # of expected passes            75832
 # of unexpected failures        2841
 # of expected failures          130
 # of known failures             75
 # of unresolved testcases       22
 # of untested testcases         37
 # of unsupported tests          83
...

Related known issues:
- PR gcc/90232 - "gcc drops top-level dies with -fdebug-types-section"
- PR gdb/25875 - "segv in ada_discrete_type_low_bound"
- PR gdb/14148 - "-fdebug-types-section regresses static scope of types"

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* boards/debug-types.exp: New file.

gdb/testsuite: Remove build paths from test names

Having paths in test names makes it harder to compare results from
different builds of GDB.

gdb/testsuite/ChangeLog:

* gdb.btrace/multi-inferior.exp: Avoid paths in test names.

Automatic date update in version.in

Remove symbol_get_demangled_name

Now that symbol_get_demangled_name is only used by general_symbol_info
methods, and because these methods already check the symbol's language
to decide what to return, symbol_get_demangled_name is no longer
needed.  This patch removes it.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* symtab.h (symbol_get_demangled_name): Don't declare.
* symtab.c (symbol_get_demangled_name): Remove.
(general_symbol_info::natural_name)
(general_symbol_info::demangled_name): Update.

Fix Rust test cases

PR rust/25025 notes that some Rust test cases fail.

Debugging gdb revealed that the Rust compiler emits different linkage
names that demangle to the same result.  Enabling complaints when
reading the test case is enough to show it:

    During symbol reading: Computed physname <generics::identity<f64>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17h8540b320af6656d6E>) - DIE at 0x424 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics]
    During symbol reading: Computed physname <generics::identity<u32>> does not match demangled <generics::identity> (from linkage <_ZN8generics8identity17hae302fad0c33bd7dE>) - DIE at 0x459 [in module /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.rust/generics/generics]
    ...

This patch changes the DWARF reader to prefer the computed physname,
rather than the output of the demangler, for Rust.  This fixes the
bug.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

PR rust/25025:
* dwarf2/read.c (dwarf2_physname): Do not demangle for Rust.

Use the linkage name if it exists

The DWARF reader has had some odd code since the "physname" patches landed.

In particular, these patches caused PR symtab/12707; namely, they made
it so "set print demangle off" no longer works.

This patch attempts to fix the problem.  It arranges to store the
linkage name on the symbol if it exists, and it changes the DWARF
reader so that the demangled name is no longer (usually) stored in the
symbol's "linkage name" field.

c-linkage-name.exp needed a tweak, because it started working
correctly.  This conforms to what I think ought to happen, so this
seems like an improvement here.

compile-object-load.c needed a small change to use
symbol_matches_search_name rather than directly examining the linkage
name.  Looking directly at the name does the wrong thing for C++.

There is still some name-related confusion in the DWARF reader:

* "physname" often refers to the logical name and not what I would
  consider to be the "physical" name;

* dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
  return different strings -- but this seems like at least one name
  too many.  For example, Fortran requires dwarf2_full_name, but other
  languages do not.

* To my surprise, dwarf2_physname prefers the form emitted by the
  demangler over the one that it computes.  This seems backward to me,
  given that the partial symbol reader prefers the opposite, and it
  seems to me that this choice may perform better as well.

I didn't attempt to clean up these things.  It would be good to do,
but whenever I contemplate it I get caught up in dreams of truly
rewriting the DWARF reader instead.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

PR symtab/12707:
* dwarf2/read.c (add_partial_symbol): Use the linkage name if it
exists.
(new_symbol): Likewise.
* compile/compile-object-load.c (get_out_value_type): Use
symbol_matches_search_name.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

PR symtab/12707:
* gdb.python/py-symbol.exp: Update expected results for
linkage_name test.
* gdb.cp/print-demangle.exp: New file.
* gdb.base/c-linkage-name.exp: Fix test.
* gdb.guile/scm-symbol.exp: Update expected results for
linkage_name test.

Don't call compute_and_set_names for partial symbols

As mentioned in another thread, there's currently no need to call
compute_and_set_names for partial symbols.  Because the DWARF partial
symbol reader constructs demangled names, this call can only demangle
a name by mistake.

So, this patch changes the DWARF reader to simply set the linkage name
on the new symbol.  This is equivalent to what was done before.  There
should be no user-visible change from this patch, aside from gdb
speeding up a bit.

... there *should* be, but this regressed
dw2-namespaceless-anonymous.exp.  However, upon examination, I think
that test is incorrect.  It puts a mangled name into DW_AT_name, and
it puts the variable at the top level, not in a namespace.  This isn't
what C++ compilers ought to do.  So, this patch also updates the test
case.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* dwarf2/read.c (add_partial_symbol): Do not call
compute_and_set_names.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* gdb.dwarf2/dw2-namespaceless-anonymous.S: Remove.
* gdb.dwarf2/dw2-namespaceless-anonymous.c: New file.
* gdb.dwarf2/dw2-namespaceless-anonymous.exp: Use DWARF
assembler.

Use the new add_psymbol_to_list overload

This changes the DWARF reader to use the new add_psymbol_to_list
overload.  There should be no visible changes due to this patch.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* dwarf2/read.c (add_partial_symbol): Use new add_psymbol_to_list
overload.

Introduce new add_psymbol_to_list overload

This adds a new overload of add_psymbol_to_list.  This one takes an
already constructed psymbol and adds it to the bcache and the
appropriate list.

This seemed cleaner than continuing to add parameters to the existing
add_psymbol_to_list, and is more in line with how full symbols are
constructed.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* psymtab.c (add_psymbol_to_bcache): Simplify calling convention.
(add_psymbol_to_list): New overload.  Make old overload call new
one.
* psympriv.h (add_psymbol_to_list): New overload.

Add attribute::value_as_string method

The full DIE reader checks that an attribute has a "string" form in
some spots, but the partial DIE reader does not.  This patch brings
the two readers in sync for one specific case, namely when examining
the linkage name.  This avoids regressions in an existing DWARF test
case.

A full fix for this problem would be preferable.  An accessor like
DW_STRING should always check the form.  However, I haven't attempted
that in this series.

Also the fact that the partial and full readers can disagree like this
is a design flaw.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* dwarf2/read.c (partial_die_info::read) <case
DW_AT_linkage_name>: Use value_as_string.
(dwarf2_string_attr): Use value_as_string.
* dwarf2/attribute.h (struct attribute) <value_as_string>: Declare
method.
* dwarf2/attribute.c (attribute::value_as_string): New method.

Fix two latent Rust bugs

Two methods on general_symbol_info did not handle the language_rust
case.  I don't think these problems can be noticed with the current
code (which is why the bugs went unnoticed), but a future patch will
change this.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* symtab.c (general_symbol_info::natural_name)
(general_symbol_info::demangled_name): Check for language_rust.

Move the rust "{" hack

The DWARF reader has a special case to work around a bug in some
versions of the Rust compiler -- it ignores mangled names that contain
a "{" character.

I noticed that this check should probably be in dw2_linkage_name
rather than only in dwarf2_physname.  The former is called in some
cases that the latter is not.

Also, I noticed that this work is not done for the partial DIE reader,
so this patch adds the check there as well.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* dwarf2/read.c (dw2_linkage_name): Move Rust "{" hack here...
(dwarf2_physname): ... from here.
(partial_die_info::read): Add Rust "{" hack.

Convert symbol_set_demangled_name to a method

This changes symbol_set_demangled_name to be a method on
general_symbol_info, and updates the users.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

* symtab.h (struct general_symbol_info) <set_demangled_name>: New
method.
(symbol_set_demangled_name): Don't declare.
* symtab.c (general_symbol_info::set_demangled_name): Rename from
symbol_set_demangled_name.
(general_symbol_info::set_language)
(general_symbol_info::compute_and_set_names): Update.
* minsyms.c (minimal_symbol_reader::install): Update.
* dwarf2/read.c (new_symbol): Update.

[gdb/testsuite] Fix language in dw2-bad-mips-linkage-name.exp

The test-case gdb.dwarf2/dw2-bad-mips-linkage-name.exp has a CU with
language C, which contains a subprogram with a C++-mangled name as its
DW_AT_mips_linkage_name attribute.

Fix this by changing the language of the CU to C++.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Set language of CU to
C++.

Update test cases that work with minimal encodings

Some test cases already work fine with minimal encodings (in some
cases perhaps due to the variant parts series) This patch updates
these tests as appropriate.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* gdb.ada/frame_arg_lang.exp: Run with multiple -fgnat-encodings
values.
* gdb.ada/funcall_ref.exp: Run with multiple -fgnat-encodings
values.  Update test for minimal encodings.
* gdb.ada/lang_switch.exp: Update test for minimal encodings.
* gdb.ada/var_rec_arr.exp: Run with multiple -fgnat-encodings
values.  Update test for minimal encodings.

Add Python support for dynamic types

This changes the gdb Python API to add support for dynamic types.  In
particular, this adds an attribute to gdb.Type, and updates some
attributes to reflect dynamic sizes and field offsets.

There's still no way to get the dynamic type from one of its concrete
instances.  This could perhaps be added if needed.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

PR python/23662:
* python/py-type.c (convert_field): Handle
FIELD_LOC_KIND_DWARF_BLOCK.
(typy_get_sizeof): Handle TYPE_HAS_DYNAMIC_LENGTH.
(typy_get_dynamic): Nw function.
(type_object_getset): Add "dynamic".
* NEWS: Add entry.

gdb/doc/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

PR python/23662:
* python.texi (Types In Python): Document new features.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

PR python/23662:
* gdb.ada/variant.exp: Add Python checks.
* gdb.rust/simple.exp: Add dynamic type checks.

Add tests for Ada changes

The previous patches largely came without test cases.  This was done
to make the patches easier to review; as most of the patches were
needed before existing tests could be updated.

This patch adds a new test and updates some existing tests to test all
the settings of -fgnat-encodings.  This ensures that tests are run
both with the old-style "magic symbol name" encoding, and the
new-style DWARF encoding.

Note that in one case, a test is modified to be more lax.  See the
comment in mi_var_array.exp.  I didn't want to fix this in this
series, as it's already complicated enough.  However, I think it could
be fixed; I will file a bug for it.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* gdb.ada/mi_var_array.exp: Try all -fgnat-encodings settings.
Make array type matching more lax.
* gdb.ada/mi_var_union.exp: Try all -fgnat-encodings settings.
* gdb.ada/mi_variant.exp: New file.
* gdb.ada/mi_variant/pck.ads: New file.
* gdb.ada/mi_variant/pkg.adb: New file.
* gdb.ada/packed_tagged.exp: Try all -fgnat-encodings settings.
* gdb.ada/unchecked_union.exp: Try all -fgnat-encodings settings.

Update Ada ptype support for dynamic types

The DWARF reader was updated to handle variant parts and some other
selected features for Ada; but the Ada "ptype" code was not touched.
This patch changes the Ada ptype code to handle the new types
properly.

Test cases for this and for some of the other code in this series are
in a separate patch.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* ada-typeprint.c (print_choices, print_variant_part)
(print_record_field_types_dynamic): New functions.
(print_record_field_types): Use print_record_field_types_dynamic.

Add support for variable field offsets

In Ada, a field can have a variable offset.  This patch adds support
for this case to gdb, using the existing dynamic type resolution code.

Doing just this, though, would break C++ virtual base handling.

It turns out that virtual base handling only worked by the ugliest of
hacks.  In particular, the DWARF reader would call decode_locdesc for
a virtual base location.  Here's an example of such an expression from
gdb's m-static test case:

    <241>   DW_AT_data_member_location: 6 byte block: 12 6 48 1c 6 22  (DW_OP_dup; DW_OP_deref; DW_OP_lit24; DW_OP_minus; DW_OP_deref; DW_OP_plus)

When examining this, decode_locdesc would treat DW_OP_deref as a no-op
and compute some answer (here, -24).  This would be stored as the
offset.

Later, in gnu-v3-abi.c, the real offset would be computed by digging
around in the vtable.

This patch cleans up this area.  In particular, it now evaluates the
location expression on demand.

Note there is a new FIXME in gnu-v3-abi.c.  I think some of the
callers are incorrect here, and have only worked because this member
is unused.  I will file a bug for this.  I didn't fix this problem in
this series because I felt it was already too complex.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (handle_data_member_location): New overload.
(dwarf2_add_field): Use it.
(decode_locdesc): Add "computed" parameter.  Update comment.
* gdbtypes.c (is_dynamic_type_internal): Also look for
FIELD_LOC_KIND_DWARF_BLOCK.
(resolve_dynamic_struct): Handle FIELD_LOC_KIND_DWARF_BLOCK.
* gdbtypes.c (is_dynamic_type_internal): Add special case for C++
virtual base classes.
* gnu-v3-abi.c (gnuv3_baseclass_offset): Handle
FIELD_LOC_KIND_DWARF_BLOCK.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* gdb.ada/variant.exp: Add dynamic field offset tests.
* gdb.ada/variant/pck.ads (Nested_And_Variable): New type.
* gdb.ada/variant/pkg.adb: Add new variables.

Add support for dynamic type lengths

In Ada, a type with variant parts can have a variable length.  This
patch adds support for this to gdb, by integrating the length
computation into the dynamic type resolution code.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (read_structure_type): Handle dynamic length.
* gdbtypes.c (is_dynamic_type_internal): Check
TYPE_HAS_DYNAMIC_LENGTH.
(resolve_dynamic_type_internal): Use TYPE_DYNAMIC_LENGTH.
* gdbtypes.h (TYPE_HAS_DYNAMIC_LENGTH, TYPE_DYNAMIC_LENGTH):
New macros.
(enum dynamic_prop_node_kind) <DYN_PROP_BYTE_SIZE>: New
constant.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* gdb.ada/variant.exp: New file
* gdb.ada/variant/pkg.adb: New file
* gdb.ada/variant/pck.adb: New file

Rewrite the existing variant part code

This rewrites the existing variant part code to follow the new model
implemented in the previous patch.  The old variant part code is
removed.

This only affects Rust for the moment.  I tested this using various
version of the Rust compiler, including one that emits old-style enum
debuginfo, exercising the quirks code.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (struct variant_field): Rewrite.
(struct variant_part_builder): New.
(struct nextfield): Remove "variant" field.  Add "offset".
(struct field_info): Add "current_variant_part" and
"variant_parts".
(alloc_discriminant_info): Remove.
(alloc_rust_variant): New function.
(quirk_rust_enum): Update.
(dwarf2_add_field): Set "offset" member.  Don't handle
DW_TAG_variant_part.
(offset_map_type): New typedef.
(convert_variant_range, create_one_variant)
(create_one_variant_part, create_variant_parts)
(add_variant_property): New functions.
(dwarf2_attach_fields_to_type): Call add_variant_property.
(read_structure_type): Don't handle DW_TAG_variant_part.
(handle_variant_part, handle_variant): New functions.
(handle_struct_member_die): Use them.
(process_structure_scope): Don't handle variant parts.
* gdbtypes.h (TYPE_FLAG_DISCRIMINATED_UNION): Remove.
(struct discriminant_info): Remove.
(enum dynamic_prop_node_kind) <DYN_PROP_DISCRIMINATED>: Remove.
(struct main_type) <flag_discriminated_union>: Remove.
* rust-lang.c (rust_enum_p, rust_empty_enum_p): Rewrite.
(rust_enum_variant): Return int.  Remove "contents".  Rewrite.
(rust_print_enum, rust_print_struct_def, rust_evaluate_subexp):
Update.
* valops.c (value_union_variant): Remove.
* value.h (value_union_variant): Don't declare.

Prefer existing data when evaluating DWARF expression

When evaluating a DWARF expression, the dynamic type resolution code
will pass in a buffer of bytes via the property_addr_info.  However,
the DWARF expression evaluator will then proceed to read memory from
the inferior, even when the request could be filled from this buffer.

This, in turn, is a problem in some cases; and specifically when
trying to handle the Ada scenario of extracting a variable-length
value from a packed array.  Here, the ordinary DWARF expression cannot
be directly evaluated, because the data may appear at some arbitrary
bit offset.  So, it is unpacked into a staging area and then the
expression is evaluated -- using an address of 0.

This patch fixes the problem by arranging for the DWARF evaluator, in
this case, to prefer passed-in memory when possible.  The type of the
buffer in the property_addr_info is changed to an array_view so that
bounds checking can be done.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_discrete_type_high_bound, ada_discrete_type_low)
(ada_value_primitive_packed_val): Update.
* ada-valprint.c (ada_value_print_1): Update.
* dwarf2/loc.c (evaluate_for_locexpr_baton): New struct.
(dwarf2_locexpr_baton_eval): Take a property_addr_info rather than
just an address.  Use evaluate_for_locexpr_baton.
(dwarf2_evaluate_property): Update.
* dwarf2/loc.h (struct property_addr_info) <valaddr>: Now an
array_view.
* findvar.c (default_read_var_value): Update.
* gdbtypes.c (compute_variant_fields_inner)
(resolve_dynamic_type_internal): Update.
(resolve_dynamic_type): Change type of valaddr parameter.
* gdbtypes.h (resolve_dynamic_type): Update.
* valarith.c (value_subscripted_rvalue): Update.
* value.c (value_from_contents_and_address): Update.

Allow DWARF expression to push the initial address

Some DWARF expressions must be evaluated by first pushing the object
address onto the evaluation stack.  This patch adds this ability.
This functionality is not used yet, but it will be used in a later
patch.  This is split out for easier review and also because it
improved the patch series ordering.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add
"push_initial_value" parameter.
(dwarf2_evaluate_property): Likewise.
* dwarf2/loc.h (dwarf2_evaluate_property): Update.

Add new variant part code

This patch adds the infrastructure for the new variant part code.  At
this point, nothing uses this code.  This is done in a separate patch
to make it simpler to review.

I examined a few possible approaches to handling variant parts.  In
particular, I considered having a DWARF variant part be a union
(similar to how the Rust code works now); and I considered having type
fields have a flag indicating that they are variants.

Having separate types seemed bad conceptually, because these variants
aren't truly separate -- they rely on the "parent" type.  And,
changing how fields worked seemed excessively invasive.

So, in the end I thought the approach taken in this patch was both
simple to implement and understand, without losing generality.  The
idea in this patch is that all the fields of a type with variant parts
will be stored in a single field array, just as if they'd all been
listed directly.  Then, the variants are attached as a dynamic
property.  These control which fields end up in the type that's
constructed during dynamic type resolution.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* gdbtypes.c (is_dynamic_type_internal): Check for variant parts.
(variant::matches, compute_variant_fields_recurse)
(compute_variant_fields_inner, compute_variant_fields): New
functions.
(resolve_dynamic_struct): Check for DYN_PROP_VARIANT_PARTS.
Use resolved_type after type is made.
(operator==): Add new cases.
* gdbtypes.h (TYPE_HAS_VARIANT_PARTS): New macro.
(struct discriminant_range, struct variant, struct variant_part):
New.
(union dynamic_prop_data) <variant_parts, original_type>: New
members.
(enum dynamic_prop_node_kind) <DYN_PROP_VARIANT_PARTS>: New constant.
(enum dynamic_prop_kind) <PROP_TYPE, PROP_VARIANT_PARTS>: New
constants.
* value.c (unpack_bits_as_long): Now public.
* value.h (unpack_bits_as_long): Declare.

Rename "variant" to "ppc_variant"

I wanted to use the name "variant" to represent a DWARF variant, but
it turned out there was an existing structure of that name.  This
renames the existing variant to "ppc_variant".

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* rs6000-tdep.c (struct ppc_variant): Rename from "variant".
(variants, find_variant_by_arch, rs6000_gdbarch_init): Update.

Add WOW64 exception numbers to $_siginfo.ExceptionCode enum

gdb/ChangeLog:

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

* windows-tdep.c (exception_values): Add WOW64 exception numbers.

Move OpenBSD-only functions from inf-ptrace to obsd-nat

All major BSDs implement PT_GET_PROCESS_STATE, but they differ in
details and want to implement follow-fork functionality differently.

gdb/ChangeLog:

* inf-ptrace.h (follow_fork, insert_fork_catchpoint)
(remove_fork_catchpoint, post_startup_inferior)
(post_attach): Move...
* obsd-nat.h (follow_fork, insert_fork_catchpoint)
(remove_fork_catchpoint, post_startup_inferior)
(post_attach): ...here.
* inf-ptrace.c (follow_fork, insert_fork_catchpoint)
(remove_fork_catchpoint, post_startup_inferior)
(post_attach): Move...
* obsd-nat.c (follow_fork, insert_fork_catchpoint)
(remove_fork_catchpoint, post_startup_inferior)
(post_attach): ...here.

[gdb/testsuite] Reset errcnt in clean_restart

When running test-case gdb.base/readnever.exp without commit 96038148d0e
"[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we
run into an error:
...
ERROR: (eof) GDB never initialized.
testcase gdb/testsuite/gdb.base/readnever.exp completed in 0 seconds
...

If we additionally run test-case gdb.base/realname-expand.exp, we get an
unresolved for the first test:
...
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...

Using -v we find out that the UNRESOLVED is due the error triggered in the
previous test-case:
...
(gdb) set basenames-may-differ on^M
(gdb) Error/Warning threshold exceeded:  1 0 (max. 1 3)
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...

So, the error count of one test spills into the next test, even though we do a
clean restart.  That seems like a bad idea.

Fix this by resetting errcnt (as well as warncnt) in clean_restart, such that
we have:
...
Running src/gdb/testsuite/gdb.base/readnever.exp ...
ERROR: (eof) GDB never initialized.
Running src/gdb/testsuite/gdb.base/realname-expand.exp ...
PASS: gdb.base/realname-expand.exp: set basenames-may-differ on
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (clean_restart): Reset errcnt and warncnt.

Fix Windows debugging regression

The updated pending stop series introduced a regression in Windows
debugging.  When stopped at a software breakpoint, we would adjust the
PC each time it was requested -- however, more than a single
adjustment is incorrect.  This patch introduces a new flag that is
used to ensure the adjustment only happens a single time.

No similar change is needed in gdbserver, because it adjusts the PC in
a different way.

I still can't run the gdb test suite on Windows, but I can run the
internal AdaCore test suite there; and this fixes the regressions
there.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tromey@adacore.com>

* nat/windows-nat.h (struct windows_thread_info)
<pc_adjusted>: New member.
* windows-nat.c (windows_fetch_one_register): Check
pc_adjusted.
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::wait): Set pc_adjusted.

[gdb/testsuite] Compile dwzbuildid-mismatch more quietly

When running test-case gdb.dwarf2/dwzbuildid.exp with target board
cc-with-gdb-index, we have:
...
Running src/gdb/testsuite/gdb.dwarf2/dwzbuildid.exp ...
gdb compile failed, warning: File "dwzbuildid5.o" has a different \
  build-id, file skipped
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch
warning: File "dwzbuildid5.o" has a different build-id, file skipped
Error while writing index for `dwzbuildid-mismatch': could not find \
  '.gnu_debugaltlink' file for dwzbuildid-mismatch
...
and likewise for target board cc-with-debug-names.

These are gdb-add-index warnings and errors due to the executable
dwzbuildid-mismatch having a build-id mismatch.

Be less verbose by adding "quiet" to the compile flags.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dwzbuildid.exp: Add quiet to dwzbuildid-mismatch compile
flags.

[gdb/testsuite] Compile gdb.dwarf2/dw2-error.exp quietly

When running test-case gdb.dwarf2/dw2-error.exp with target board
cc-with-gdb-index, we get:
...
Running src/gdb/testsuite/gdb.dwarf2/dw2-error.exp ...
gdb compile failed, Dwarf Error: wrong version in compilation unit header \
  (is 153, should be 2, 3, 4 or 5) [in module \
  build/gdb/testsuite/outputs/gdb.dwarf2/dw2-error/.tmp/dw2-error]
...
and similar for target board cc-with-debug-names.

Be less verbose by adding "quiet" to the compile flags.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-error.exp: Add quiet to compile flags.

[gdb/testsuite] Reduce errors after gdb exit in default_gdb_start

When running test-case gdb.base/readnever.exp with target board readnow, and
without commit 96038148d0e "[gdb/testsuite] Skip gdb.base/readnever.exp with
target board readnow", we run into a bunch of errors, starting with:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
  --readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp9 not open
    while executing
"expect {
-i exp9 -timeout 10
        -re "$gdb_prompt $" {
            verbose "Setting height to 0." 2
        }
...

The illegal combination of --readnow and --readnever causes gdb to start,
print an error message and exit.  There's a gdb_expect in default_gdb_start
that is supposed to detect the initial gdb prompt and handle related problems,
but since there's no eof case it succeeds, and default_gdb_start continues as
if the gdb prompt had been detected, causing the error above.

Fix this by adding an eof case to the gdb_expect, such that we have the more
accurate:
...
ERROR: (eof) GDB never initialized.
...

Further errors are triggered in clean_restart, because we're not testing for
gdb_start success.  Fix this by detecting gdb_start failure, and bailing out.

Finally, we're running into further errors in gdb.base/readnever.exp because
we're not testing for clean_restart success.  Fix this by making clean_restart
return -1 upon error, and testing for this.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (default_gdb_start): Handle eof.
(clean_restart): Detect and handle gdb_start failure.  Return -1 upon
failure.
* gdb.base/readnever.exp: Handle clean_restart failure.

[gdb/contrib] Use temp dir for gdb-add-index in cc-with-tweaks.sh

When running test-case gdb.dwarf2/gdb-index.exp cleanly by issuing this
command:
...
$ rm -Rf build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index
...
before running, it passes both with native and target board
cc-with-gdb-index.

But when we run the test-case first with native and then with
cc-with-gdb-index without intermediate cleanup, we get instead:
...
 Running src/gdb/testsuite/gdb.dwarf2/gdb-index.exp ...
 gdb compile failed, cc-with-tweaks.sh: Index file \
   build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index \
   exists, won't clobber.

                 === gdb Summary ===

 # of untested testcases         1
...

What happens is that the native run produces a file
build/gdb/testsuite/outputs/gdb.dwarf2/gdb-index/gdb-index.gdb-index, which
causes gdb/contrib/cc-with-tweaks.sh to hit this code:
...
index_file="${output_file}.gdb-index"
if [ "$want_index" = true ] && [ -f "$index_file" ]
then
    echo "$myname: Index file $index_file exists, won't clobber." >&2
    exit 1
fi
...

The gdb-add-index script has a problem that it uses temp files alongside the
executable, filed as PR25843.

The code in cc-with-tweaks.sh attempts to detect the case that creating such a
temp file would overwrite an pre-existing file.  It however does this only for
a single file, while gdb-add-index uses more temporary files:
- <exec>.gdb-index
- <exec>.debug_names
- <exec>.debug_str
- <exec>.debug_str.merge
- <exec>.debug_str.err

Fix this by working around PR25843 in a more generic way:
- move the executable into a temp directory
- execute gdb-add-index, allowing it to create any temp file alongside the
  executable in the temp directory
- move the executable back to the original location

Tested on x86_64-linux, with target board cc-with-debug-index.

gdb/ChangeLog:

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

* contrib/cc-with-tweaks.sh: Remove <exec>.gdb-index file handling.
Run gdb-add-index inside temp dir.

readelf: memory leaks in process_dynamic_section

This fixes some code that assumed only one PT_LOAD would contain
DT_SYMTAB.  Which is normally the case, but fuzzers thoroughly mess
with object files.

* readelf.c (get_num_dynamic_syms): Check for nbuckets and nchains
non-zero.
(process_dynamic_section): Call get_num_dynamic_syms once rather
than in segment loop.  Break out of segment loop on a successful
load of dynamic symbols.  Formatting.
(process_object): Return error status from process_dynamic_section.

Automatic date update in version.in

Fix infinite loop in is_linked_with_cygwin_dll

There were some Windows timeouts after the last merge.  Debugging
showed that these were caused by an infinite loop in
is_linked_with_cygwin_dll when reading C:\Windows\SysWOW64\win32u.dll.

This patch fixes the problem by ensuring that the loop always makes
progress.

gdb/ChangeLog
2020-04-23  Tom Tromey  <tromey@adacore.com>

* windows-tdep.c (is_linked_with_cygwin_dll): Always update "iter"
in loop.

Fix inline frame unwinding breakage

There has been some breakage for aarch64-linux, arm-linux and s390-linux in
terms of inline frame unwinding. There may be other targets, but these are
the ones i'm aware of.

The following testcases started to show numerous failures and trigger internal
errors in GDB after commit 1009d92fc621bc4d017029b90a5bfab16e17fde5,
"Find tailcall frames before inline frames".

gdb.opt/inline-break.exp
gdb.opt/inline-cmds.exp
gdb.python/py-frame-inline.exp
gdb.reverse/insn-reverse.exp

The internal errors were of this kind:

binutils-gdb/gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.

After a lengthy investigation to try and find the cause of these assertions,
it seems we're dealing with some fragile/poorly documented code to handle inline
frames and we are attempting to unwind from this fragile section of code.

Before commit 1009d92fc621bc4d017029b90a5bfab16e17fde5, the tailcall sniffer
was invoked from dwarf2_frame_prev_register. By the time we invoke the
dwarf2_frame_prev_register function, we've probably already calculated the
frame id (via compute_frame_id).

After said commit, the call to dwarf2_tailcall_sniffer_first was moved to
dwarf2_frame_cache. This is very early in a frame creation process, and
we're still calculating the frame ID (so compute_frame_id is in the call
stack).

This would be fine for regular frames, but the above testcases all deal
with some inline frames.

The particularity of inline frames is that their frame ID's depend on
the previous frame's ID, and the previous frame's ID relies in the inline
frame's registers. So it is a bit of a messy situation.

We have comments in various parts of the code warning about some of these
particularities.

In the case of dwarf2_tailcall_sniffer_first, we attempt to unwind the PC,
which goes through various functions until we eventually invoke
frame_unwind_got_register. This function will eventually attempt to create
a lazy value for a particular register, and this lazy value will require
a valid frame ID.  Since the inline frame doesn't have a valid frame ID
yet (remember we're still calculating the previous frame's ID so we can tell
what the inline frame ID is) we will call compute_frame_id for the inline
frame (level 0).

We'll eventually hit the assertion above, inside get_frame_id:

--
      /* If we haven't computed the frame id yet, then it must be that
         this is the current frame.  Compute it now, and stash the
         result.  The IDs of other frames are computed as soon as
         they're created, in order to detect cycles.  See
         get_prev_frame_if_no_cycle.  */
      gdb_assert (fi->level == 0);
--

It seems to me we shouldn't have reached this assertion without having the
inline frame ID already calculated. In fact, it seems we even start recursing
a bit when we invoke get_prev_frame_always within inline_frame_this_id. But
a check makes us quit the recursion and proceed to compute the id.

Here's the call stack for context:

 #0  get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2109
 RECURSION - #1  0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
 #2  0x0000aaaaaae95768 in inline_frame_this_id (this_frame=0xaaaaab85a670, this_cache=0xaaaaab85a688, this_id=0xaaaaab85a6d0)
     at ../../../repos/binutils-gdb/gdb/inline-frame.c:165
 #3  0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:550
 #4  0x0000aaaaaae19318 in get_frame_id (fi=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:582
 #5  0x0000aaaaaae13480 in value_of_register_lazy (frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/findvar.c:296
 #6  0x0000aaaaaae16c00 in frame_unwind_got_register (frame=0xaaaaab85a730, regnum=30, new_regnum=30) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:268
 #7  0x0000aaaaaad52604 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=30)
     at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1296
 #8  0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1229
 #9  0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=30) at ../../../repos/binutils-gdb/gdb/frame.c:1320
 #10 0x0000aaaaaab76574 in aarch64_dwarf2_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
     at ../../../repos/binutils-gdb/gdb/aarch64-tdep.c:1114
 #11 0x0000aaaaaad52724 in dwarf2_frame_prev_register (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, regnum=32)
     at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1316
 #12 0x0000aaaaaae1ae68 in frame_unwind_register_value (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1229
 #13 0x0000aaaaaae1b304 in frame_unwind_register_unsigned (next_frame=0xaaaaab85a730, regnum=32) at ../../../repos/binutils-gdb/gdb/frame.c:1320
 #14 0x0000aaaaaae16a84 in default_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame-unwind.c:223
 #15 0x0000aaaaaae32124 in gdbarch_unwind_pc (gdbarch=0xaaaaab81edc0, next_frame=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/gdbarch.c:3074
 #16 0x0000aaaaaad4f15c in dwarf2_tailcall_sniffer_first (this_frame=0xaaaaab85a730, tailcall_cachep=0xaaaaab85a830, entry_cfa_sp_offsetp=0x0)
     at ../../../repos/binutils-gdb/gdb/dwarf2/frame-tailcall.c:388
 #17 0x0000aaaaaad520c0 in dwarf2_frame_cache (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748) at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1190
 #18 0x0000aaaaaad52204 in dwarf2_frame_this_id (this_frame=0xaaaaab85a730, this_cache=0xaaaaab85a748, this_id=0xaaaaab85a790)
     at ../../../repos/binutils-gdb/gdb/dwarf2/frame.c:1218
 #19 0x0000aaaaaae1916c in compute_frame_id (fi=0xaaaaab85a730) at ../../../repos/binutils-gdb/gdb/frame.c:550
 #20 0x0000aaaaaae1c958 in get_prev_frame_if_no_cycle (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:1927
 #21 0x0000aaaaaae1cc44 in get_prev_frame_always_1 (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2006
 FIRST CALL - #22 0x0000aaaaaae1d098 in get_prev_frame_always (this_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:2124
 #23 0x0000aaaaaae18f68 in skip_artificial_frames (frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:495
 #24 0x0000aaaaaae193e8 in get_stack_frame_id (next_frame=0xaaaaab85a670) at ../../../repos/binutils-gdb/gdb/frame.c:596
 #25 0x0000aaaaaae87a54 in process_event_stop_test (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6857
 #26 0x0000aaaaaae86bdc in handle_signal_stop (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:6381
 #27 0x0000aaaaaae84fd0 in handle_inferior_event (ecs=0xffffffffefc8) at ../../../repos/binutils-gdb/gdb/infrun.c:5578
 #28 0x0000aaaaaae81588 in fetch_inferior_event (client_data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:4020
 #29 0x0000aaaaaae5f7fc in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at ../../../repos/binutils-gdb/gdb/inf-loop.c:43
 #30 0x0000aaaaaae8d768 in infrun_async_inferior_event_handler (data=0x0) at ../../../repos/binutils-gdb/gdb/infrun.c:9377
 #31 0x0000aaaaaabff970 in check_async_event_handlers () at ../../../repos/binutils-gdb/gdb/async-event.c:291
 #32 0x0000aaaaab27cbec in gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:194
 #33 0x0000aaaaaaef1894 in start_event_loop () at ../../../repos/binutils-gdb/gdb/main.c:356
 #34 0x0000aaaaaaef1a04 in captured_command_loop () at ../../../repos/binutils-gdb/gdb/main.c:416
 #35 0x0000aaaaaaef3338 in captured_main (data=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1254
 #36 0x0000aaaaaaef33a0 in gdb_main (args=0xfffffffff1f0) at ../../../repos/binutils-gdb/gdb/main.c:1269
 #37 0x0000aaaaaab6e0dc in main (argc=6, argv=0xfffffffff348) at ../../../repos/binutils-gdb/gdb/gdb.c:32

The following patch addresses this by using a function that unwinds the PC
from the next (inline) frame directly as opposed to creating a lazy value
that is bound to the next frame's ID (still not computed).

gdb/ChangeLog:

2020-04-23  Luis Machado  <luis.machado@linaro.org>

* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Use
get_frame_register instead of gdbarch_unwind_pc.

[gdb/symtab] Prefer def over decl (inter-CU case, with context)

This is a follow-up patch on "[PATCH][gdb/symtab] Prefer def over decl
(inter-CU case)" (
https://sourceware.org/pipermail/gdb-patches/2020-April/167489.html ).

Consider the test-case from that patch.  It contains a decl and def of var a
in different CUs, and tests whether var a can be printed using the def, even
if the decl is found first.

However, the test-case does this in a contextless environment, so if we add to
the test-case like this to set the context to the CU containing main:
...
 gdb_test "p a" { = \{1, 2\}}
+
+if ![runto_main] then {
+    fail "can't run to main"
+    return 0
+}
+
+gdb_test "p a" { = \{1, 2\}}
...
then the second test fails, because the decl is found in the context.

Fix this by preferring defs over decls in lookup_global_symbol.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

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

* symtab.c (lookup_global_symbol): Prefer def over decl.

gdb/testsuite/ChangeLog:

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

* gdb.base/decl-before-def.exp: Run to main and print a again.

[gdb/symtab] Prefer def over decl (inter-CU case)

When running test-case gdb.threads/tls.exp with target board -readnow, we
have:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while with native we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...

The difference in behaviour can be explained as follows.  Without -readnow, we
have two a_thread_locals, the def and the decl, each in a different CU:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot read `a_thread_local' without registers
 int a_thread_local; computed at runtime
 int a_thread_local; unresolved
...
and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls  \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
 int a_thread_local; unresolved
 int a_thread_local; computed at runtime
...

Fix the FAIL by preferring the def over the decl (something we already do
intra-CU since the fix for PR24971, commit 93e55f0a03 "[gdb/symtab] Prefer var
def over decl").

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

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

PR symtab/25807
* block.c (best_symbol, better_symbol): Promote to external.
* block.h (best_symbol, better_symbol): Declare.
* symtab.c (lookup_symbol_in_objfile_symtabs): Prefer def over
decl.

gdb/testsuite/ChangeLog:

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

* gdb.base/decl-before-def-decl.c: New test.
* gdb.base/decl-before-def-def.c: New test.
* gdb.base/decl-before-def.exp: New file.

Fix Ada crash with .debug_names

PR ada/25837 points out a crash in the gdb testsuite when .debug_names
is used.  You can reproduce like:

    runtest --target_board=cc-with-debug-names \
        gdb.ada/big_packed_array.exp

The bug was introduced by commit e0802d599 ("Avoid copying in
lookup_name_info").  The problem is that the return type of
language_lookup_name changed, but in a way that didn't cause existing
callers to trigger a compilation error.  Previously, it returned a
"const string &", but after it returned a "const char *".  This caused
a string to be created in dw2_expand_symtabs_matching_symbol, but one
that had too short of a lifetime; so eventually the matcher cache
would wind up with invalid data.

This patch fixes the problem by updating the callers to use the new
type.

Tested on x86-64 Fedora 30.

gdb/ChangeLog
2020-04-23  Tom Tromey  <tromey@adacore.com>

PR ada/25837:
* dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Store a
"const char *", not a "const std::string &".
<name_and_matcher::operator==>: Update.
* unittests/lookup_name_info-selftests.c: Change type of
"result".

Remove iterate_over_inferiors

The last caller of iterate_over_inferiors is darwin-nat.c.  This patch
removes the calls from this file, and then remove
iterate_over_inferiors.

In general I think "external iteration" is to be preferred in gdb, the
main benefit being that the code is easier to read.

I rebuilt this on Darwin.  I seem to only have access to Darwin
systems where gdb does not yet work :-(, so I can't run the test
suite.

gdb/ChangeLog
2020-04-23  Tom Tromey  <tom@tromey.com>

* inferior.h (iterate_over_inferiors): Don't declare.
* inferior.c (iterate_over_inferiors): Remove.
* darwin-nat.c (find_inferior_task_it, find_inferior_pid_it):
Remove.
(darwin_find_inferior_by_task, darwin_find_inferior_by_pid): Don't
use iterate_over_inferiors.
(darwin_resume_inferior_it)
(struct resume_inferior_threads_param)
(darwin_resume_inferior_threads_it): Remove.
(darwin_nat_target::resume): Don't use iterate_over_inferiors.

Change-Id: Ib2fdf2c98e40f13156ff869ed3173d5f1fdae7ea

arc: Add support for ARC HS extra registers in core files

When a coredump is generated, there are a few registers in
ARC HS that are put under a special section, namely ".reg-v2".
It is for backward compatibility reasons with older tools that
we have decided not to extend the generic ".reg" section.

This patch makes it possible to display the information better
regarding that section.  Compare the output of "readelf" without
and with these changes:

$ readelf -n core     # without the patch
  ...
  LINUX    0x0000000c  Unknown note type: (0x00000600)
   description data: 78 08 00 00 2f 6c 64 2d 75 43 6c 69

$ readelf -n core     # with the patch
  ...
  LINUX    0x0000000c  NT_ARC_V2 (ARC HS accumulator/extra registers)
   description data: 78 08 00 00 2f 6c 64 2d 75 43 6c 69

In another commit (soon to be submitted), GDB will makes use of these
changes to parse the extra section and its registers.

bfd/ChangeLog
2020-03-26  Anton Kolesov  <anton.kolesov@synopsys.com>

* elf-bfd.h (elfcore_write_arc_v2): Add prototype.
* elf.c (elfcore_grok_arc_v2): New function.
(elfcore_grok_note): Call the new function to handle the corresponding
note.
(elfcore_write_arc_v2): New function.
(elfcore_write_register_note): Call the new function to handle the
corresponding pseudo-sections.

binutils/ChangeLog
2020-03-26  Anton Kolesov  <anton.kolesov@synopsys.com>

* readelf.c (get_note_type): Handle NT_ARC_V2.

include/elf/ChangeLog
2020-03-26  Anton Kolesov  <anton.kolesov@synopsys.com>

* common.h (NT_ARC_V2): New macro definitions.

[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow

When running test-case gdb.base/readnever.exp with target board readnow, we
have:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
  --readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp19 not open
...

Fix this by skipping the test when -readnow/--readnow is detected in
GDBFLAGS.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/readnever.exp: Skip if GDBFLAGS contain -readnow/--readnow.

[gdb/symtab] Fix disassembly of non-contiguous functions

When running test-case gdb.dwarf2/dw2-ranges-func.exp with target board
readnow, we have:
...
FAIL: gdb.dwarf2/dw2-ranges-func.exp: disassemble foo (pattern 2)
...

The function foo consists of two ranges:
...
 <1><12f>: Abbrev Number: 7 (DW_TAG_subprogram)
    <130>   DW_AT_external    : 1
    <131>   DW_AT_name        : foo
    <135>   DW_AT_ranges      : 0x40
...
which are listed here:
...
    00000040 00000000004004c1 00000000004004dc
    00000040 00000000004004ae 00000000004004ba
...

Normally the disassemble instruction lists both ranges, but with -readnow it
only lists the first.

This is due to function find_pc_partial_function, which only interacts with
partial symtabs, but not with expanded ones.

Fix this by using find_pc_sect_compunit_symtab in find_pc_partial_function.

Tested on x86_64, with native and target board readnow.

This fixes 19 FAILs for target board readnow, in test-cases
gdb.arch/amd64-entry-value.exp, gdb.base/multi-forks.exp,
gdb.dwarf2/dw2-ranges-func.exp and gdb.linespec/skip-two.exp.

gdb/ChangeLog:

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

* blockframe.c (find_pc_partial_function): Use
find_pc_sect_compunit_symtab rather than
objfile->sf->qf->find_pc_sect_compunit_symtab.

xtensa: fix PR ld/25861

Introduce new relaxations XTENSA_PDIFF{8,16,32} for positive differences
(subtracted symbol precedes diminished symbol) and XTENSA_NDIFF{8,16,32}
for negative differences (subtracted symbol follows diminished symbol).
Don't generate XTENSA_DIFF relocations in the assembler, generate
XTENSA_PDIFF or XTENSA_NDIFF based on relative symbol position.

Handle XTENSA_DIFF in BFD for compatibility with old object files.
Handle XTENSA_PDIFF and XTENSA_NDIFF in BFD, treating difference value
as unsigned.

2020-04-22  Max Filippov  <jcmvbkbc@gmail.com>
bfd/
* bfd-in2.h: Regenerated.
* elf32-xtensa.c (elf_howto_table): New entries for
R_XTENSA_PDIFF{8,16,32} and R_XTENSA_NDIFF{8,16,32}.
(elf_xtensa_reloc_type_lookup, elf_xtensa_do_reloc)
(relax_section): Add cases for R_XTENSA_PDIFF{8,16,32} and
R_XTENSA_NDIFF{8,16,32}.
* libbfd.h (bfd_reloc_code_real_names): Add names for
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32}.
* reloc.c: Add documentation for BFD_RELOC_XTENSA_PDIFF{8,16,32}
and BFD_RELOC_XTENSA_NDIFF{8,16,32}.

binutils/
* readelf.c (is_none_reloc): Recognize
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32}.

gas/
* config/tc-xtensa.c (md_apply_fix): Replace
BFD_RELOC_XTENSA_DIFF{8,16,32} generation with
BFD_RELOC_XTENSA_PDIFF{8,16,32} and
BFD_RELOC_XTENSA_NDIFF{8,16,32} generation.
* testsuite/gas/xtensa/loc.d: Replace BFD_RELOC_XTENSA_DIFF16
with BFD_RELOC_XTENSA_PDIFF16 in the expected output.

include/
* elf/xtensa.h (elf_xtensa_reloc_type): New entries for
R_XTENSA_PDIFF{8,16,32} and R_XTENSA_NDIFF{8,16,32}.

ld/
* testsuite/ld-xtensa/relax-loc.d: New test definition.
* testsuite/ld-xtensa/relax-loc.s: New test source.
* testsuite/ld-xtensa/xtensa.exp (relax-loc): New test.

Automatic date update in version.in

Add myself as maintainer for PDP11.

Fix search of large memory area in gdbserver

If the search area is bigger than SEARCH_CHUNK_SIZE (16000), then you get
an error in gdbserver:
gdb: (gdb) find /w 0x3c43f0,+20000,0x04030201
gdb: Pattern not found.
gdbserver: Unable to access 3997 bytes of target memory at 0x3c8273, halting search.

The return value of any additional gdb_read_memory calls were compared with the
wrong value, this fixes it.

gdbserver/ChangeLog:

2020-04-22  Hannes Domani  <ssbssa@yahoo.de>

* server.cc (handle_search_memory_1): Fix gdb_read_memory return value
comparison.

Remove Chris Faylor as the ix86 PE maintainer.

* MAINTAINERS: Remove Chris Faylor as the ix86 PE maintainer.

For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths.

PR ld/25806
* ldlang.h (struct lang_input_statement_struct): Add extra_search_path.
* ldlang.c (current_input_file): New.
(ldirname): New.
(new_afile): Add from_filename parameter. Set extra_search_path.
(lang_add_input_file): Pass current_input_file to new_afile.
(load_symbols): Set current_input_file.

.symver fixes

* config/obj-elf.c (elf_frob_symbol): Unconditionally remove
symbol for ".symver .. remove".
* doc/as.texi (.symver): Update.
* testsuite/gas/symver/symver11.s: Make foo weak.
* testsuite/gas/symver/symver11.d: Expect an error.
* testsuite/gas/symver/symver7.d: Allow other random symbols.

[gdb/testsuite] Fix .debug_ranges in gdb.mi/dw2-ref-missing-frame-func.c

While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.mi/dw2-ref-missing-frame-func.c contains a hardcoded 0:
...
"      .4byte  0 \n" // .Ldebug_info0 - Offset of Compilation Unit Info
...

So when looking for an address in the range 0x4004a7-0x4004bf, we should find
the CU at 0xc7:
...
  Compilation Unit @ offset 0xc7:
   Length:        0xba (32-bit)
   Version:       2
   Abbrev Offset: 0x64
   Pointer Size:  4
 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d3>   DW_AT_high_pc     : 0x4004bf
    <d7>   DW_AT_low_pc      : 0x4004a7
    <db>   DW_AT_name        : file1.txt
    <e5>   DW_AT_producer    : GNU C 3.3.3
    <f1>   DW_AT_language    : 1        (ANSI C)
...
but instead the .debug_aranges entry points us to the CU at 0x0:
...
  Length:                   28
  Version:                  2
  Offset into .debug_info:  0x0
  Pointer Size:             4
  Segment Size:             0

    Address    Length
    004004a7 00000018
    00000000 00000000
...

Fix this by using a label to refer to the start of the CU, similar to how
that's done for gdb.dlang/watch-loc.c in the fix for PR24522:
...
"      .4byte  .Lcu1_begin\n" // .Ldebug_info0 - Offset of Compilation Unit Info
...

The label marks the start of the empty .debug_info section for
dw2-ref-missing-frame-func.c, which is supposed to merge with the .debug_info
section in dw2-ref-missing-frame.S, so in order for that to work, we need to
make sure dw2-ref-missing-frame-func.o comes before dw2-ref-missing-frame.o in
the link line.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.mi/dw2-ref-missing-frame-func.c (.debug_aranges): Fix
debug_info_offset.
* gdb.mi/dw2-ref-missing-frame.exp: Make sure $objfuncfile comes
before $objsfile in the line line.

Correct mingw target select

x86_64-w64-mingw32  +FAIL: ld-scripts/default-script1
x86_64-w64-mingw32  +FAIL: ld-scripts/default-script2
x86_64-w64-mingw32  +FAIL: ld-scripts/default-script3
x86_64-w64-mingw32  +FAIL: ld-scripts/default-script4

* testsuite/ld-scripts/default-script1.d: Correct mingw skip.
* testsuite/ld-scripts/default-script2.d: Likewise.
* testsuite/ld-scripts/default-script3.d: Likewise.
* testsuite/ld-scripts/default-script4.d: Likewise.

readelf: move file related static vars to filedata

The idea here is to get rid of a lot of file related static vars used
to pass data around, in order to not have stale data about one object
file persisting to the next one.

* readelf.c (archive_file_offset, archive_file_size, dynamic_addr),
(dynamic_size, dynamic_nent, dynamic_strings, dynamic_strings_length),
(num_dynamic_syms, nbuckets, nchains, buckets, chains),
(ngnubuckets, gnubuckets, gnuchains, mipsxlat, ngnuchains),
(gnusymidx, dynamic_symbols, dynamic_syminfo, dynamic_syminfo_offset),
(dynamic_syminfo_nent, program_interpreter, dynamic_info),
(dynamic_info_DT_GNU_HASH, dynamic_info_DT_MIPS_XHASH, version_info),
(dynamic_section, symtab_shndx_list, group_count, section_groups),
(section_headers_groups): Move to struct filedata.  Update use
throughout file.

readelf: cmdline data

Don't use a struct filedata for cmdline, which only needs two of the
filedata fields.

* readelf.c (struct dump_data): New, used..
(cmdline): ..here, and..
(struct filedata): ..here.  Adjust all uses.
(request_dump_bynumber, request_dump, parse_args): Pass in a
struct dump_data* rather than Filedata*.  Adjust callers.
(main): Don't set cmdline.file_name.

[gdb/testsuite] Fix .debug_aranges in gdb.dlang/watch-loc.c

While investigating PR25862 (an assertion failure with target board
cc-with-debug-names), I noticed that the .debug_aranges section in
gdb.dlang/watch-loc.c contains a hardcoded 0x1000:
...
"      .4byte  _Dmain \n"      // Address
"      .4byte  0x1000 \n"      // Length
...

Fix this by using the actual length of _Dmain, along the lines of how that
is done in gdb.mi/dw2-ref-missing-frame-func.c:
...
"      .4byte  _Dmain_end - _Dmain \n" // Length
...
such that the .debug_aranges entry:
...
    Address    Length
    004004a7 0000000b
    00000000 00000000
...
matches the addresses found in the corresponding CU:
...
 <2><fd>: Abbrev Number: 6 (DW_TAG_subprogram)
    <fe>   DW_AT_name        : _Dmain
    <105>   DW_AT_low_pc      : 0x4004a7
    <10d>   DW_AT_high_pc     : 0x4004b2
...

With this fix the assertion failure is no longer triggered for
gdb.dlang/watch-loc.exp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dlang/watch-loc.c (.debug_aranges): Fix _Dmain length.

ChangeLog entries for my last changes.

[gdb/symtab] Store external var decls in psymtab

Consider a test-case consisting of source file test.c:
...
extern int aaa;
int
main (void)
{
  return 0;
}
...
and test-2.c:
...
int aaa = 33;
...
compiled with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...

When trying to print aaa, we get:
...
$ gdb -batch a.out -ex "print aaa"
'aaa' has unknown type; cast it to its declared type
...
but with -readnow we have:
...
$ gdb -readnow -batch a.out -ex "print aaa"
$1 = 33
...

In the -readnow case, the symbol for aaa in the full symtab has
LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol
address, to read the value and print it without cast.

Without the -readnow, we create partial symbols, but the aaa decl is missing
from the partial symtabs, so we find it only in the minimal symbols, resulting
in the cast request.  If the aaa decl would have been in the partial symtabs,
it would have been found, and the full symtab would have been expanded, after
which things would be as with -readnow.

The function add_partial_symbol has a comment on the LOC_UNRESOLVED +
minimal symbol addres construct at DW_TAG_variable handling:
...
      else if (pdi->is_external)
{
  /* Global Variable.
     Don't enter into the minimal symbol tables as there is
     a minimal symbol table entry from the ELF symbols already.
     Enter into partial symbol table if it has a location
     descriptor or a type.
     If the location descriptor is missing, new_symbol will create
     a LOC_UNRESOLVED symbol, the address of the variable will then
     be determined from the minimal symbol table whenever the variable
     is referenced.
...
but it's not triggered due to this test in scan_partial_symbols:
...
            case DW_TAG_variable:
    ...
              if (!pdi->is_declaration)
                {
                  add_partial_symbol (pdi, cu);
                }
...

Fix this in scan_partial_symbols by allowing external variable decls to be
added to the partial symtabs.

Build and reg-tested on x86_64-linux.

The patch caused this regression:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while without the patch we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...

However, without the patch but with -readnow we have the same FAIL as with the
patch (filed as PR25807).  In other words, the patch has the effect that we
get the same result with and without -readnow.

This can be explained as follows.  Without the patch, and without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot read `a_thread_local' without registers
 int a_thread_local; computed at runtime
 int a_thread_local; unresolved
...
while without the patch and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls  \
    -ex "maint expand-symtabs" \
    -ex "print a_thread_local" \
    -ex "maint print symbols" \
    | grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
 int a_thread_local; unresolved
 int a_thread_local; computed at runtime
...

With the patch we have the same order with and without -readnow, but just a
different one than before without -readnow.

Mark the "Cannot find thread-local variables on this target" variant a PR25807
kfail.

gdb/ChangeLog:

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

PR symtab/25764
* dwarf2/read.c (scan_partial_symbols): Allow external variable decls
in psymtabs.

gdb/testsuite/ChangeLog:

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

PR symtab/25764
* gdb.base/psym-external-decl-2.c: New test.
* gdb.base/psym-external-decl.c: New test.
* gdb.base/psym-external-decl.exp: New file.
* gdb.threads/tls.exp: Add PR25807 kfail.

[gdb/symtab] Find filename in shared psymtab

When running test-case gdb.ada/dgopt.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects and gcc-8, gcc-9 or
gcc-10, and the fix for PR25700, we run into this regression:
...
(gdb) list x.adb:16, 16^M
No source file named x.adb.^M
(gdb) FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...

The reason for the failure is that without the fix for PR25700, we
have an unshared psymtab:
...
  { psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
    readin no^M
    fullname (null)^M
    text addresses 0x0 -- 0x0^M
    psymtabs_addrmap_supported yes^M
    globals (none)^M
    statics (none)^M
    dependencies (none)^M
  }^M
...
and a shared psymtab (with user field set):
...
  { psymtab gdb.ada/dgopt/x.adb ((struct partial_symtab *) $hex)^M
    readin no^M
    fullname (null)^M
    text addresses 0x0 -- 0x0^M
    psymtabs_addrmap_supported yes^M
    globals (none)^M
    statics (none)^M
    user <artificial>@0x159a ((struct partial_symtab *) 0x37b57c0)^M
    dependencies (none)^M
  }^M
...

The fix for PR25700 removes the unshared psymtab.

Then when trying to find a psymtab matching x.adb in
psym_map_symtabs_matching_filename, we run into this continue for the shared
psymtab:
...
  for (partial_symtab *pst : require_partial_symbols (objfile, true))
    {
      /* We can skip shared psymtabs here, because any file name will be
        attached to the unshared psymtab.  */
      if (pst->user != NULL)
       continue;
...
and consequently cannot find the file.

Fix this by not skipping the shared symtab in
psym_map_symtabs_matching_filename.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

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

PR symtab/25801
* psymtab.c (psym_map_symtabs_matching_filename): Don't skip shared
symtabs.

gdb/testsuite/ChangeLog:

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

PR symtab/25801
* gdb.dwarf2/imported-unit.exp: Test that we can get imported_unit.c
in "info source" output.

[gdb/symtab] Don't create duplicate psymtab for forward-imported CU

Consider the executable generated for test-case gdb.dwarf2/imported-unit.exp.

When loading the executable using various tracing:
...
$ gdb \
  outputs/gdb.dwarf2/imported-unit/imported-unit \
  -batch \
  -iex "set verbose on" \
  -iex "set debug symtab-create 1"
  ...
Created psymtab 0x213f380 for module <artificial>@0xc7.
Created psymtab 0x20e7b00 for module imported_unit.c.
Created psymtab 0x215da20 for module imported_unit.c.
Created psymtab 0x2133630 for module elf-init.c.
Created psymtab 0x215b910 for module ../sysdeps/x86_64/crtn.S.
...
we notice that there are two psymtabs generated for imported_unit.c.

This is due to the following: in dwarf2_build_psymtabs_hard we loop over CUs
and generate partial symtabs for those, and if we encounter an import of
another CU, we also generate a partial symtab for that one, unless already
created.

This works well with backward import references:
- the imported CU is read
- then the importing CU is read
- the import is encountered, but the imported CU is already read, so
  we're done.

But with forward import references, we have instead:
- the importing CU is read
- the import is encountered, and the imported CU is read
- the imported CU is read once more

Fix this by skipping already created psymtabs in the loop in
dwarf2_build_psymtabs_hard.

Tested on x86_64-linux, with native and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects.

This causes this regression with the target board:
...
FAIL: gdb.ada/dgopt.exp: list x.adb:16, 16
...
which I consider a seperate PR, filed as PR25801 - "Filename of shared psymtab
is ignored".

gdb/ChangeLog:

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

PR symtab/25700
* dwarf2/read.c (dwarf2_build_psymtabs_hard): Don't create psymtab for
CU if already created.

gdb/testsuite/ChangeLog:

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

PR symtab/25700
* gdb.dwarf2/imported-unit.exp: Verify that there's only one partial
symtab for imported_unit.c.

symver11.s: Add ".balign 8"

Add ".balign 8" to avoid

symver11.s:9: Error: misaligned data

for sh targets.

* testsuite/gas/symver/symver11.s: Add ".balign 8".

Automatic date update in version.in

Fix compilation errors with clang in gdb.base/advance.c

Clang fails to compile the above file, with the following errors:
  warning: control reaches end of non-void function [-Wreturn-type]
  warning: too many arguments in call to 'func'

This prevents the following testcases from executing:
  gdb.base/advance.exp
  gdb.base/until-nodebug.exp

gdb/testsuite/ChangeLog:

* gdb.base/advance.c (func): New argument, to match call site.
(func2, func3): Add return statements.

gdb/infrun: switch the context before 'displaced_step_restore'

In infrun.c's 'displaced_step_fixup', as part of the 'finish_step_over'
flow, switch to the eventing thread *before* calling
'displaced_step_restore', because down in the flow ptid-dependent
memory accesses are used via current_inferior() and current_top_target().

Without this patch, the problem is exposed with the scenario below:

   $ gdb -q
   (gdb) maint set target-non-stop on
   (gdb) file a.out
   Reading symbols from a.out...
   (gdb) set remote exec-file a.out
   (gdb) target extended-remote | gdbserver --once --multi -
   ...
   (gdb) add-inferior
   [New inferior 2]
   Added inferior 2 on connection 1 (extended-remote ...)
   (gdb) inferior 2
   [Switching to inferior 2 [<null>] (<noexec>)]
   (gdb) file a.out
   Reading symbols from a.out...
   (gdb) set remote exec-file a.out
   (gdb) run
   ...
   Cannot access memory at address 0x555555555042
   (gdb)

The problem is, down inside 'displaced_step_restore', GDB wants to
access the memory for inferior 2 because of an internal breakpoint.
However, the current inferior and inferior_ptid are out of sync.
While inferior_ptid correctly points to the process of inf 2 that was
just started, current_inferior points to inf 1.  Then, the attempt to
access the memory fails, because target_has_execution results in false
since inf 1 was not started.  I was not able to simplify the failing
scenario, but it shows the problem.

After this patch, we get

  ... same steps above...
  (gdb) run
  ...
  [Inferior 2 (process 28652) exited normally]
  (gdb)

Regression-tested on X86_64 Linux with `make check`s default board file
and also `--target_board=native-extended-gdbserver`.  In fact, the bug
fixed by this patch was exposed when using the native-extended-gdbserver
board file.

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

* infrun.c (displaced_step_fixup): Switch to the event_thread
before calling displaced_step_restore, not after.

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

* gdb.multi/run-only-second-inf.c: New file.
* gdb.multi/run-only-second-inf.exp: New file.

Disallow PC relative for CMPI on MC68000/10

The MC68000/10 decodes the second operand of CMPI strictly as destination
operand, which disallows PC relative addressing, even though the insn
doesn't write to the operand.  This restriction has only been lifted for
the MC68020+ and CPU32.

opcodes:
PR 25848
* m68k-opc.c (m68k_opcodes): Allow pc-rel for second operand of
cmpi only on m68020up and cpu32.

gas:
PR 25848
* testsuite/gas/m68k/operands.s: Add tests for cmpi.
* testsuite/gas/m68k/operands.d: Update.
* testsuite/gas/m68k/op68000.d: Update for new error messages.