[gdb/testsuite] Fix internal buffer full error in gdb.fortran/module.exp

With test-case gdb.fortran/module.exp, I run into:
...
PASS: gdb.fortran/module.exp: fully qualified name of DW_TAG_constant
ERROR: internal buffer is full.
UNRESOLVED: gdb.fortran/module.exp: info variables -n
...

Fix this by using exp_continue while matching the output of "info variable
-n".

Tested on x86_64-linux, using make targets check and check-read1.

gdb/testsuite/ChangeLog:

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

* gdb.fortran/module.exp: Use exp_continue during matching of output
of "info variable -n".

[gdb/testsuite] Fix dw2-ranges-base.exp FAIL with lib debuginfo

When running test-case gdb.dwarf2/dw2-ranges-base.exp with debuginfo for
various libs installed, I run into:
...
(gdb) maint info line-table^M
  ...
objfile: /usr/lib/debug/lib64/ld-2.26.so-2.26-lp151.18.7.x86_64.debug \
  ((struct objfile *) 0x1a9d7f0)^M
compunit_symtab: ((struct compunit_symtab *) 0x2061090)^M
symtab: /usr/src/debug/glibc-2.26-lp151.18.7.x86_64/sysdeps/generic/\
  dl-fcntl.h ((struct symtab *) 0x2182660)^M
linetable: ((struct linetable *) 0x0):^M
No line table.^M
(gdb) FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table
...

The test-case intends to count 3 END markers in the line table for
gdb.dwarf2/dw2-ranges-base.c:
...
symtab: /data/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/\
  dw2-ranges-base.c ((struct symtab *) 0x2a7e8c0)^M
linetable: ((struct linetable *) 0x2a7ea60):^M
INDEX    LINE ADDRESS IS-STMT^M
0          31 0x00000000004004a7 Y^M
1          21 0x00000000004004ae Y^M
2         END 0x00000000004004ae Y^M
3          11 0x00000000004004ba Y^M
4         END 0x00000000004004ba Y^M
5         END 0x00000000004004c6 Y^M
...
but ends up counting 70+ END markers for all line tables.

Fix this by limiting the line tables emitted by the maint info line-table
command.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-ranges-base.exp: Limit "maint info line-table" to
gdb.dwarf2/dw2-ranges-base.c.

[gdb/testsuite] Fix gdb.linespec/explicit.exp FAIL with glibc debug info

When running test-case gdb.linespec/explicit.exp with GLIBC debuginfo
installed, I run into:
...
(gdb) break -source exp^GlFAIL: gdb.linespec/explicit.exp: complete \
  non-unique file name (timeout)
...

The regexp that times out is:
...
           -re "break -source exp\\\x07licit" {
...
and the reason it times out is that gdb only outputs an "l" after the tab, while
the regexp expect a futher "icit".

This is a regression since commit 507dd60e28 "[gdb/testsuite, 1/2] Fix
gdb.linespec/explicit.exp with check-read1", where I merged the matching for
the two cases where GLIBC debuginfo is either installed or not, as it turns
out incorrectly, presumably because even though I tested with GLIBC debuginfo
info installed and deinstalled, that didn't make a difference because I didn't
use configure flag --with-separate-debug-dir=/usr/lib/debug.

Fix this by not explictly matching the "icit" part.

Tested on x86_64-linux, with and without GLIBC debuginfo installed, both with
make targets check and check-read1.

gdb/testsuite/ChangeLog:

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

* gdb.linespec/explicit.exp: Fix "complete non-unique file name" test
in presence of GLIBC debuginfo.

[gdb/testsuite] Use string_to_regexp on core filename in gdb_core_cmd

In commit 1281424ccf "[gdb/testsuite] Fix core file load FAIL in
tls-core.exp", I've made this change:
...
-       -re ": No such file or directory.*\r\n$gdb_prompt $" {
+       -re "$core: No such file or directory.*\r\n$gdb_prompt $" {
...

However, the $core variable contains a filename which needs to be matched
as a literal string, not as a regexp.

Fix this by using string_to_regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (gdb_core_cmd): Use string_to_regexp for regexp-matching
$core.

[gdb/testsuite] Fix core file load FAIL in tls-core.exp

After deinstalling package glibc-debugsource, I run into the following FAIL
with test-case gdb.threads/tls-core.exp:
...
(gdb) core gdb/testsuite/outputs/gdb.threads/tls-core/tls-core.core^M
[New LWP 30081]^M
[New LWP 30080]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Core was generated by `gdb/testsuite/outputs/gdb.threads/tls-core/tls-c'.^M
Program terminated with signal SIGABRT, Aborted.^M
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.^M
[Current thread is 1 (Thread 0x7fb568d4b700 (LWP 30081))]^M
(gdb) FAIL: gdb.threads/tls-core.exp: native: load core file (file not found)
...

The problem is that this gdb_test_multiple clause in gdb_core_cmd:
...
       -re ": No such file or directory.*\r\n$gdb_prompt $" {
           fail "$test (file not found)"
           return -1
       }
...
triggers on the message about raise.c, while it is intended to catch:
...
$ gdb
(gdb) core bla
/home/vries/bla: No such file or directory.
...

Fix this by making the regexp more precise:
...
-       -re ": No such file or directory.*\r\n$gdb_prompt $" {
+       -re "$core: No such file or directory.*\r\n$gdb_prompt $" {
...

Tested on x86_64-linux.

Also tested the test-case with this patch in place to verify that the regexp
still triggers:
...
-       set core_loaded [gdb_core_cmd $corefile $test]
+       set core_loaded [gdb_core_cmd $corefile/bla $test]
...

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (gdb_core_cmd): Make "No such file or directory" regexp
more precise.

asan: readelf leaks

* readelf.c (process_section_headers): Don't just set
filedata->section_headers NULL, free it first.  Similarly for
dynamic_symbols, dynamic_strings, dynamic_syminfo and
symtab_shndx_list.  Zero associated counts too.
(process_object): Free symtab_shndx_list.
(process_file): Free various allocated filedata tables.

Avoid infinite recursion in find_pc_sect_line

A patch somewhat like this patch has been in Fedora GDB for well over
a decade.  The Fedora patch was written by Jan Kratochvil.  The Fedora
version prints a warning and attempts to continue.  This version will
error out, fatally.  An earlier version of this patch was more like
the Fedora version than this one.  Simon Marchi recommended use of an
assertion to test for the infinite recursion; I decided to use an
explicit test (with an "if" statement) along with a call to
internal_error() if the condition is met.  This way, I could include
a plea to file a bug report.

It was motivated by a customer reported bug (back in 2006!) which
showed infinite mutual recursion between find_pc_sect_line and
find_pc_line.  Here is a portion of the backtrace from the bug report:

    (gdb) bt
    #0  0x00000000004450a4 in lookup_minimal_symbol_by_pc_section (
pc=251700325328, section=0x570f500) at gdb/minsyms.c:484
    #1  0x00000000004bbfb2 in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2057
    #2  0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
    #3  0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081

    ...   (lots and lots of the same two functions with the same parameters)

    #1070 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
    #1071 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
    #1072 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
    #1073 0x00000000004bc1ff in find_pc_sect_line (pc=251700325328,
section=0x570f500, notcurrent=0) at gdb/symtab.c:2081
    #1074 0x00000000004bc480 in find_pc_line (pc=251700325328, notcurrent=0)
at gdb/symtab.c:2232
    #1075 0x00000000004bc1ff in find_pc_sect_line (pc=251696794399,
section=0x59b0df8, notcurrent=0) at gdb/symtab.c:2081
    #1076 0x00000000004bc480 in find_pc_line (pc=251696794399, notcurrent=0)
at gdb/symtab.c:2232
    #1077 0x000000000055550e in find_frame_sal (frame=0xb3f3e0, sal=0x7fff1d1a8200)
at gdb/frame.c:1392
    #1078 0x00000000004d86fd in set_current_sal_from_frame (frame=0x1648, center=1)
at gdb/stack.c:379
    #1079 0x00000000004cf137 in normal_stop () at gdb/infrun.c:3147
    ...

The test case was a large application.  Attempts were made to make a
small(er) test case, but those attempts were not successful.
Therefore, I cannot provide a new test for this patch.

That said, we ought to guard against recursively calling
find_pc_sect_line (via find_pc_line) with the identical PC value that
it had been called with.  Should this happen, infinite recursion (as
shown in the above backtrace) is the result.  This patch prevents
that from happening.

If this should happens, there is a bug somewhere, perhaps in GDB, perhaps
in some other part of the toolchain or a library.  We error out fatally
with a message briefly describing the condition along with a plea to file
a bug report.

I spent some time looking at the surrounding code and commentary which
handle the case of PC being in a stub/trampoline.  It first appeared
in the public GDB repository in April, 1999.  The ChangeLog entry for
this commit is from 1998-12-31.  The relevant portion is:

(find_pc_sect_line): Return correct information if pc is in import
or export stub (trampoline).

What's remarkable about the overall ChangeLog entry is that it's over
2500+ lines long!  I believe that this was part of the infamous "HP
merge" (in which insufficient due diligence was given in accepting
a large batch of changes from an outside source).  In the years that
followed, much of this code was either significantly revised or
outright removed.

For this particular case, I'm grateful that extensive comments were
provided by "RT".  (I haven't been able to figure out who RT is/was.)
I've decided against attempting to revise this stub/trampoline handling
code any further than adding Jan's test which prevents an obvious case
of infinite recursion.

I've tested on Fedora 31, x86-64.  I see no regressions.  I've also
searched the logfile for the new message, but as expected, no message
was found (which is good).

gdb/ChangeLog:

* symtab.c (find_pc_sect_line): Add check which prevents infinite
recursion.

Change-Id: I595470be6ab5f61ca7e4e9e70c61a252c0deaeaa

testsuite: use `pwd -W` to convert from Unix to Windows paths

When on a MinGW host, standard_output_file uses a regular expression to
convert Unix-style paths of the form "/c/foo" to "c:/foo".  This is
needed because the paths we pass to GDB (for example, with the "file"
command) need to be in the Windows form.

However, the regexp only works if your binutils-gdb repo is under a
`/[a-z]/...` path (the Unix paths mapping to Windows drives).
Presumably, that works if you clone the repo in Windows, then access it
through `/c/...`.

In my case, I've cloned the repository directly inside my MinGW shell,
so in /home/smarchi.  The regexp therefore doesn't work for me.  The
path doesn't get transformed, and the file command fails when running
any test:

    (gdb) file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
    /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent: No such file or directory.

A safer way to do this is to execute `pwd -W` while in the directory we
want the path for, this is what this patch does.

I have also considered using the using the cygpath utility to do the
conversion.  It can be used to convert any MinGW path into its Windows
equivalent.  Despite originally coming from Cygwin, the cygpath utility
is distributed by MinGW-w64 and can be used in that environment.
However, it's not distributed with the non-MinGW-w64 MinGW.

The `pwd -W` trick only works with directories that exist, which is the
case here, so it's sufficient.

With this, the file command in the test succeeds:

    (gdb) file C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
    Reading symbols from C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent...

gdb/testsuite/ChangeLog:

* lib/gdb.exp (standard_output_file): Use `pwd -W` to convert
from Unix to Windows path.

gdb: enable -Wmissing-prototypes warning

While compiling with clang, I noticed it didn't catch cases where my
function declaration didn't match my function definition.  This is
normally caught by gcc with -Wmissing-declarations.

On clang, this is caught by -Wmissing-prototypes instead.

Note that on gcc, -Wmissing-prototypes also exists, but is only valid
for C and Objective-C.  It gets correctly rejected by the configure
script since gcc rejects it with:

    cc1plus: error: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ -Werror

So this warning flag ends up not used for gcc (which is what we want).

gdb/ChangeLog:

* configure: Re-generate.

gdbserver/ChangeLog:

* configure: Re-generate.

gdbsupport/ChangeLog:

* configure: Re-generate.
* warning.m4: Enable -Wmissing-prototypes.

[gdb/testsuite] Set language in gdb.ada/minsym.exp

When building gdb using configure flag
--with-separate-debug-dir=/usr/lib/debug, and running test-case
gdb.ada/minsyms.exp, I run into:
...
(gdb) PASS: gdb.ada/minsyms.exp: print some_minsym
print integer(some_minsym)^M
A syntax error in expression, near `some_minsym)'.^M
(gdb) FAIL: gdb.ada/minsyms.exp: print integer(some_minsym)
...
and 2 other FAILs.

This is due to the fact that the language after arriving at the ada main
function turns out to be auto/c.  [ This has been filed as PR25655 -
"Language is not auto/ada in main ada function for exec without debug info". ]

When building gdb without the configure flag mentioned above, we have instead
auto/ada in the ada main function, and all tests pass.

Fix the FAILs by working around PR25655 in the test-case, and manually setting
the language to ada.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.ada/minsyms.exp: Set language to ada.

NEWS: Mention x86 assembler options for CVE-2020-0551

* NEWS: Mention x86 assembler options for CVE-2020-0551.

[gdb/testsuite] Fix printf regexp in gdb.server/sysroot.exp

When running gdb.server/sysroot.exp, I run into this FAIL:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, __printf (format=0x4005c4 "Hello World!\n") at printf.c:28^M
28      {^M
(gdb) FAIL: gdb.server/sysroot.exp: sysroot=local: continue to printf
...
for this test:
...
    gdb_test "continue" "Breakpoint $decimal.* printf .*" "continue to printf"
...

Without debug info for glibc installed, we have instead:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00007ffff773c550 in printf () from /lib64/libc.so.6^M
(gdb) PASS: gdb.server/sysroot.exp: sysroot=local: continue to printf
...

Fix this by allowing for GLIBC's printf alias __printf to be printed:
...
    gdb_test "continue" "Breakpoint $decimal.* (__)?printf .*" \
      "continue to printf"
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.server/sysroot.exp: Allow GLIBC's printf alias __printf.

i386: Add tests for lfence with load/indirect branch/ret

Add tests for -mlfence-after-load=, -mlfence-before-indirect-branch=
and -mlfence-before-ret=.

* testsuite/gas/i386/i386.exp: Run new tests.
* testsuite/gas/i386/lfence-byte.d: New file.
* testsuite/gas/i386/lfence-byte.e: Likewise.
* testsuite/gas/i386/lfence-byte.s: Likewise.
* testsuite/gas/i386/lfence-indbr-a.d: Likewise.
* testsuite/gas/i386/lfence-indbr-b.d: Likewise.
* testsuite/gas/i386/lfence-indbr-c.d: Likewise.
* testsuite/gas/i386/lfence-indbr.e: Likewise.
* testsuite/gas/i386/lfence-indbr.s: Likewise.
* testsuite/gas/i386/lfence-load.d: Likewise.
* testsuite/gas/i386/lfence-load.s: Likewise.
* testsuite/gas/i386/lfence-ret-a.d: Likewise.
* testsuite/gas/i386/lfence-ret-b.d: Likewise.
* testsuite/gas/i386/lfence-ret.s: Likewise.
* testsuite/gas/i386/x86-64-lfence-byte.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-byte.e: Likewise.
* testsuite/gas/i386/x86-64-lfence-byte.s: Likewise.
* testsuite/gas/i386/x86-64-lfence-indbr-a.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-indbr-b.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-indbr-c.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-indbr.e: Likewise.
* testsuite/gas/i386/x86-64-lfence-indbr.s: Likewise.
* testsuite/gas/i386/x86-64-lfence-load.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-load.s: Likewise.
* testsuite/gas/i386/x86-64-lfence-ret-a.d: Likewise.
* testsuite/gas/i386/x86-64-lfence-ret-b.d: Likewise.

i386: Generate lfence with load/indirect branch/ret [CVE-2020-0551]

Add 3 command-line options to generate lfence for load, indirect near
branch and ret to help mitigate:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0551

1. -mlfence-after-load=[no|yes]:
  -mlfence-after-load=yes generates lfence after load instructions.
2. -mlfence-before-indirect-branch=[none|all|memory|register]:
  a. -mlfence-before-indirect-branch=all generates lfence before indirect
  near branches via register and a warning before indirect near branches
  via memory.
  b. -mlfence-before-indirect-branch=memory issue a warning before
  indirect near branches via memory.
  c. -mlfence-before-indirect-branch=register generates lfence before
  indirect near branches via register.
Note that lfence won't be generated before indirect near branches via
register with -mlfence-after-load=yes since lfence will be generated
after loading branch target register.
3. -mlfence-before-ret=[none|or|not]
  a. -mlfence-before-ret=or generates or with lfence before ret.
  b. -mlfence-before-ret=not generates not with lfence before ret.

A warning will be issued and lfence won't be generated before indirect
near branch and ret if the previous item is a prefix or a constant
directive, which may be used to hardcode an instruction, since there
is no clear instruction boundary.

* config/tc-i386.c (lfence_after_load): New.
(lfence_before_indirect_branch_kind): New.
(lfence_before_indirect_branch): New.
(lfence_before_ret_kind): New.
(lfence_before_ret): New.
(last_insn): New.
(load_insn_p): New.
(insert_lfence_after): New.
(insert_lfence_before): New.
(md_assemble): Call insert_lfence_before and insert_lfence_after.
Set last_insn.
(OPTION_MLFENCE_AFTER_LOAD): New.
(OPTION_MLFENCE_BEFORE_INDIRECT_BRANCH): New.
(OPTION_MLFENCE_BEFORE_RET): New.
(md_longopts): Add -mlfence-after-load=,
-mlfence-before-indirect-branch= and -mlfence-before-ret=.
(md_parse_option): Handle -mlfence-after-load=,
-mlfence-before-indirect-branch= and -mlfence-before-ret=.
(md_show_usage): Display -mlfence-after-load=,
-mlfence-before-indirect-branch= and -mlfence-before-ret=.
(i386_cons_align): New.
* config/tc-i386.h (i386_cons_align): New.
(md_cons_align): New.
* doc/c-i386.texi: Document -mlfence-after-load=,
-mlfence-before-indirect-branch= and -mlfence-before-ret=.

[gdb/testsuite] Fix stepi pattern in gdb.btrace/reconnect.exp

When running gdb.btrace/reconnect.exp, I run into the follow FAIL:
...
(gdb) stepi 19^M
0x00007ffff7dd8b67      59        return (ElfW(Addr)) &_DYNAMIC - \
  elf_machine_dynamic ();^M
(gdb) FAIL: gdb.btrace/reconnect.exp: first: stepi 19
...

The corresponding test looks like:
...
  gdb_test "stepi 19" "0x.* in .* from .*"
...
which matches the usual:
...
(gdb) stepi 19^M
0x00007ffff7dd8b67 in _dl_start () from target:/lib64/ld-linux-x86-64.so.2^M
(gdb) PASS: gdb.btrace/reconnect.exp: first: stepi 19
...
which I also get when removing configure flag
--with-separate-debug-dir=/usr/lib/debug.

Fix this by allowing the source line pattern in the test regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.btrace/reconnect.exp: Allow source line pattern after stepi.

Fix comment in ada-typeprint.c

A comment in ada-typeprint.c mentions the Unchecked_Variant pragma.
However, this does not exist, and the comment should actually mention
Unchecked_Union.

gdb/ChangeLog
2020-03-11  Tom Tromey  <tromey@adacore.com>

* ada-typeprint.c (print_choices): Fix comment.

Mark discriminants as artificial in gdb.dwarf2/variant.exp

While working on a variant part patch, I notcied that
gdb.dwarf2/variant.exp does not mark the discriminant members as
DW_AT_artificial.  However, it should, as this is what the real Rust
compiler does, and how the Rust language support is supposed to work.

gdb/testsuite/ChangeLog
2020-03-11  Tom Tromey  <tromey@adacore.com>

* gdb.dwarf2/variant.exp: Mark discriminants as artificial.

[gdb/testsuite] Fix FAILs due to verbose in foll-fork.exp

When running test-case gdb.base/foll-fork.exp, I see:
...
(gdb) catch fork^M
Catchpoint 2 (fork)^M
Reading in symbols for ../sysdeps/x86/libc-start.c...^M
(gdb) FAIL: gdb.base/foll-fork.exp: explicit child follow, set catch fork
...

The problem is that the test regexp does not expect the "Reading in symbols"
message:
...
    gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
        "explicit child follow, set catch fork"
...
which is generated due to the verbose setting.

Fix this by allowing the message in the regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/foll-fork.exp: Allow "Reading in symbols" messages.

[gdb/testsuite] Limit verbose scope in gdb.base/break-interp.exp

I'm running into the following failure (and 17 more like it) in
gdb.base/break-interp.exp:
...
 (gdb) bt^M
 #0  0x00007fde85a3b0c1 in __GI___nanosleep \
   (requested_time=requested_time@entry=0x7ffe5044ee70, \
   remaining=remaining@entry=0x7ffe5044ee70) at nanosleep.c:27^M
 #1  0x00007fde85a3affa in __sleep (seconds=0) at sleep.c:55^M
 #2  0x00007fde8606789c in libfunc (Reading in symbols for libc-start.c...^M
 action=0x7ffe5044fa12 "sleep") at gdb.base/break-interp-lib.c:41^M
 #3  0x0000000000400708 in main ()^M
 Reading in symbols for ../sysdeps/x86_64/start.S...^M
 (gdb) FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: \
   BINprelinkNOdebugNOpieNO: INNER: attach: attach main bt
...

The problem is that the test uses verbose mode to detect the "PIE (Position
Independent Executable) displacement" messages, but the verbose mode also
triggers "Reading in symbols for" messages, which may appear in the middle of
a backtrace (or not, depending on whether debug info is available).

[ In fact, the messages appear in the middle of a backtrace line, which is
PR25613. ]

Fix these FAILs by limiting the scope of verbose to the parts of the test that
need it.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/break-interp.exp: Limit verbose scope.

asan: som: unknown read

* som.c (setup_sections): Sanity check subspace.name.

[gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp

With test-case gdb.fortran/logical.exp, I run into:
...
(gdb) PASS: gdb.fortran/logical.exp: var=l: get hexadecimal valueof "&l"
set *((uint8_t *) 0x7fffffffd2bc) = 0xff^M
No symbol "uint8_t" in current context.^M
(gdb) FAIL: gdb.fortran/logical.exp: var=l: byte 0: set contents of byte at offset 0
...

Fix this by using the fortran-native type character instead.

Tested on x86_64-linux, with gcc 7.5.0.

gdb/testsuite/ChangeLog:

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

* gdb.fortran/logical.f90: Define variable with character type.
* gdb.fortran/logical.exp: Use character type instead of uint8_t.

gdb: Fix out of bounds array access in buildsym_compunit::record_line

This commit:

  commit 8c95582da858ac981f689a6f599acacb8c5c490f
  Date:   Mon Dec 30 21:04:51 2019 +0000

      gdb: Add support for tracking the DWARF line table is-stmt field

Introduced an invalid memory access, by reading outside the bounds of
an array.

This would cause this valgrind error:

  ==7633== Invalid read of size 4
  ==7633==    at 0x4D002C: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:688)
  ==7633==    by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
  ==7633==    by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
  ==7633==    by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
  ==7633==    by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
  ==7633==    by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
  ==7633==    by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
  ==7633==    by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
  ==7633==    by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
  ==7633==    by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)
  ==7633==    by 0x5DAB58: process_queue(dwarf2_per_objfile*) (read.c:8867)
  ==7633==    by 0x5CB30E: dw2_do_instantiate_symtab(dwarf2_per_cu_data*, bool) (read.c:2374)
  ==7633==  Address 0xa467f48 is 8 bytes before a block of size 16,024 alloc'd
  ==7633==    at 0x4C2CDCB: malloc (vg_replace_malloc.c:299)
  ==7633==    by 0x451FC4: xmalloc (alloc.c:60)
  ==7633==    by 0x4CFFDF: buildsym_compunit::record_line(subfile*, int, unsigned long, bool) (buildsym.c:678)
  ==7633==    by 0x5F60A5: dwarf_record_line_1(gdbarch*, subfile*, unsigned int, unsigned long, bool, dwarf2_cu*) (read.c:19956)
  ==7633==    by 0x5F63B0: lnp_state_machine::record_line(bool) (read.c:20024)
  ==7633==    by 0x5F5DD5: lnp_state_machine::handle_special_opcode(unsigned char) (read.c:19851)
  ==7633==    by 0x5F6706: dwarf_decode_lines_1(line_header*, dwarf2_cu*, int, unsigned long) (read.c:20135)
  ==7633==    by 0x5F6C57: dwarf_decode_lines(line_header*, char const*, dwarf2_cu*, dwarf2_psymtab*, unsigned long, int) (read.c:20328)
  ==7633==    by 0x5DF5F1: handle_DW_AT_stmt_list(die_info*, dwarf2_cu*, char const*, unsigned long) (read.c:10748)
  ==7633==    by 0x5DF823: read_file_scope(die_info*, dwarf2_cu*) (read.c:10796)
  ==7633==    by 0x5DDA63: process_die(die_info*, dwarf2_cu*) (read.c:9815)
  ==7633==    by 0x5DD44A: process_full_comp_unit(dwarf2_per_cu_data*, language) (read.c:9580)

gdb/ChangeLog:

* buildsyms.c (buildsym_compunit::record_line): Avoid accessing
previous item in the list, when the list has no items.

Add support for generating DWARF-5 format directory and file name tables from the assembler.

PR 25611
PR 25614
* dwarf.h (DWARF2_Internal_LineInfo): Add li_address_size and
li_segment_size fields.
* dwarf.c (read_debug_line_header): Record the address size and
segment selector size values (if present) in the lineinfo
structure.
(display_formatted_table): Warn if the format count is empty but
the table itself is not empty.
Display the format count and entry count at the start of the table
dump.
(display_debug_lines_raw): Display the address size and segement
selector size fields, if present.
* testsuite/binutils-all/dw5.W: Update expected output.

gas * dwarf2dbg.c (DWARF2_FILE_TIME_NAME): Default to -1.
(DWARF2_FILE_SIZE_NAME): Default to -1.
(DWARF2_LINE_VERSION): Default to the current dwarf level or 3,
whichever is higher.
(DWARF2_LINE_MAX_OPS_PER_INSN): Provide a default value of 1.
(NUM_MD5_BYTES): Define.
(struct file entry): Add md5 field.
(get_filenum): Delete and replace with...
(get_basename): New function.
(get_directory_table_entry): New function.
(allocate_filenum): New function.
(allocate_filename_to_slot): New function.
(dwarf2_where): Use new functions.
(dwarf2_directive_filename): Add support for extended .file
pseudo-op.
(dwarf2_directive_loc): Allow the use of file number zero with
DWARF 5 or higher.
(out_file_list): Rename to...
(out_dir_and_file_list): Add DWARF 5 support.
(out_debug_line): Emit extra values into the section header for
DWARF 5.
(out_debug_str): Allow for file 0 to be used with DWARF 5.
* doc/as.texi (.file): Update the description of this pseudo-op.
* testsuite/gas/elf-dwarf-5-file0.s: Add more lines.
* testsuite/gas/elf-dwarf-5-file0.d: Update expected dump output.
* testsuite/gas/lns/lns-diag-1.l: Update expected error message.
* NEWS: Mention the new feature.

[gdb/testsuite] Set EDITOR to true before using edit

The test-case gdb.base/list-ambiguous.exp normally passes, but with target
board readnow, some tests fail.

In particular, for this test, edit doesn't fail as expected:
...
    # While at it, test the "edit" command as well, since it shares
    # code with "list".
    gdb_test "edit $symbol" \
        "Specified line is ambiguous:\r\n${h0_re}\r\n${h1_re}"
...
and the editor is launched, in my case:
...
$ echo $EDITOR
/home/vries/bin/emacs-nw.sh
...
which result in all subsequent tests failing with timeout, and an editor
backup file in my sources:
...
$ git status --ignored
On branch master
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

        gdb/testsuite/gdb.base/#list-ambiguous0.c#

nothing to commit, working tree clean
...

Fix this by setting EDITOR to true before starting gdb in this test-case.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/list-ambiguous.exp: Set EDITOR to true.

libctf: Mark bswap_identity_64 inline function as static.

This is similar to cbbbc402e059ee345cb781d3ceb757ae1cc679ee and fixes
a link error with duplicately defined symbols on FreeBSD.

libctf/ChangeLog:

* swap.h (bswap_identity_64): Make static.

powerpc64-ld infinite loop

If this code dealing with possible conversion of inline plt sequences
is ever executed, ld will hang.  A binary with such sequences and of
code size larger than approximately 90% the reach of an unconditional
branch is the trigger.  Oops.

* elf64-ppc.c (ppc64_elf_inline_plt): Do increment rel in for loop.

PR25651, objcopy SIGSEGV in copy_object

With the right set of options, the second block of code dealing with
padding can see a different section count.  So don't use the new count.
Since I was editing those lines, I've also changed the code allocating
arrays a little.
    array = malloc (n * sizeof (*array));
for an array of ints is just better than
    array = malloc (n * sizeof (int));
It's easier to write correctly in the first place and more robust
against code changes that might modify the array element type.

PR 25651
* objcopy.c (copy_object): Test "gaps" not gap_fill_set or
pad_to_set on second block of code dealing with padding.
Replace "c" with "num_sec" and don't recalculate number of
sections on second block.  Size arrays using sizeof (element)
rather than sizeof (element type).

Don't merge sections with differing MASKPROC or MASKOS flags

Not just SHF_EXCLUDE but any of these flags ought to prevent merging
of sections for ld -r.

* ldelf.c (elf_orphan_compatible): Return false when two sections
have differing SHF_MASKPROC or SHF_MASKOS flags.

[gdb] Fix segv in "maint print symbols" for ada exec

When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
   ...
     info: array (<>) of character; computed at runtime
     ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...

What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL.  Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.

Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

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

* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.

gdb/testsuite/ChangeLog:

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

* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.

gdb: Add support for tracking the DWARF line table is-stmt field

This commit brings support for the DWARF line table is_stmt field to
GDB.  The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.

The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.

Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.

Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks.  This can easily be incorrect in code with even a low
level of optimisation.

With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.

When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.

When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.

Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.

The original motivation for this work was a patch posted by Bernd
here:
  https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html

As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future.  The spec
is here:
  http://dwarfstd.org/ShowIssue.php?issue=170427.1

And Bernd gives a brief description of the benefits here:
  https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html

With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.

The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
  https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html

gdb/ChangeLog:

* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range.  Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.

gdb/testsuite/ChangeLog:

* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.

gdb/testsuite: Add is-stmt support to the DWARF compiler

This commit adds the ability to set and toggle the DWARF line table
is-stmt flag.

A DWARF line table can now be created with the attribute
'default_is_stmt' like this:

  lines {version 2 default_is_stmt 0} label {
    ...
  }

If 'default_is_stmt' is not specified then the current default is 1,
which matches the existing behaviour.

Inside the DWARF line table program you can now make use of
{DW_LNS_negate_stmt} to toggle the is-stmt flag, for example this
meaningless program:

  lines {version 2 default_is_stmt 0} label {
    include_dir "some_directory"
    file_name "some_filename" 1

    program {
      {DW_LNS_negate_stmt}
      {DW_LNE_end_sequence}
    }
  }

This new functionality will be used in a later commit.

gdb/testsuite/ChangeLog:

* lib/dwarf.exp (Dwarf::lines) Add support for modifying the
is-stmt flag in the line table.

Change-Id: Ia3f61d523826382dd2333f65b9aae368ad29c4a5

More 1 << 31 signed overflows

* config/tc-csky.c (get_operand_value): Rewrite 1 << 31 expressions
to avoid signed overflow.
* config/tc-mcore.c (md_assemble): Likewise.
* config/tc-mips.c (gpr_read_mask, gpr_write_mask): Likewise.
* config/tc-nds32.c (SET_ADDEND): Likewise.
* config/tc-nios2.c (nios2_assemble_arg_R): Likewise.

ubsan: som: left shift of 1 by 31 places

* som/aout.h (SOM_AUX_ID_MANDATORY, SOM_SPACE_IS_LOADABLE),
(SOM_SYMBOL_HIDDEN, SOM_SYMBOL_HAS_LONG_RETURN): Use 1u << 31.
* som/lst.h (LST_SYMBOL_HIDDEN): Likewise.

objdump disassembly of files without symbols

ubsan complains about memcpy with a NULL src even when size is zero.

* objdump.c (disassemble_section): Don't call qsort unless
sym count is at least two.
(disassemble_data): Don't call memcpy with NULL src.

PR25648, objcopy SIGSEGV in ihex_write_record

ihex_set_section_contents sorts records stored on the tdata.ihex_data
list by address, but ihex_write_object_contents went too far in
assuming they were not overlapping.  This patch fixes the problem by
not assuming anything about addresses in ihex_write_object_contents.

PR 25648
* ihex.c (ihex_write_object_contents): Don't assume ordering of
addresses here.  Remove dead code.

x86: Also pass -P to $(CPP) when processing i386-opc.tbl

Since i386-opc.tbl contains '\' to avoid very long lines and i386-gen
requires that each instruction must be in one line, also pass -P to
$(CPP) to inhibit generation of linemarkers in the output from the
preprocessor to support i386-gen.

* Makefile.am ($(srcdir)/i386-init.h): Also pass -P to $(CPP).
* Makefile.in: Regenerated.

[gdb/testsuite] Fix tcl error in cached_file

When trying to run tests using target board cc-with-dwz after a clean build, I
run into:
...
ERROR: tcl error sourcing board description file for target cc-with-tweaks.exp.
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
  no such file or directory
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
  no such file or directory
    while executing
"open $tmp_filename w"
    (procedure "cached_file" line 9)
    invoked from within
"cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1"
...

The problem is that cached_file is trying to create a file
build/gdb/testsuite/cache/gdb.sh.17028 in a non-existing directory.

Fix this by creating the cache dir in cached_file.

Tested on x86_64-linux, with target board cc-with-tweaks, and native.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (cached_file): Create cache dir.

PR25645, readelf segfault reading fuzzed alpha-vms binary

PR 25645
* readelf.c (dump_ia64_vms_dynamic_fixups): Pass size and nmemb
to get_data rather than multiplying.
(dump_ia64_vms_dynamic_relocs): Likewise.
(process_version_sections): Correct order of size and nmemb args
in get_data call.
(process_mips_specific): Likewise.

x86: use template for AVX512 integer comparison insns

These all follow a common pattern.

x86: use template for XOP integer comparison, shift, and rotate insns

These all follow common patterns.

x86: use template for AVX/AVX512 floating point comparison insns

These all follow an almost common pattern, again with the exception of
being commutative, which can be easily taken care of.

Note that, as an intended side effect (and in fact one of the reason to
introduce templates), AVX long-form pseudo-ops get introduced alongside
the already existing AVX512 ones.

x86: use template for SSE floating point comparison insns

These all follow an almost common pattern, with the exception of being
commutative. This exception can be easily taken care of.

x86: allow opcode templates to be templated

In order to reduce redundancy as well as the chance of things going out
of sync (see a later patch for an example), make the opcode table
generator capable of recognizing and expanding templated templates. Use
the new capability for compacting the general purpose conditional insns.

readelf.c: Fix a typo in comments

* readelf.c (get_dynamic_data): Replace "memory chekers" with
"memory checkers" in comments.

asan: wasm: Out-of-memory

* wasm-module.c (wasm_scan): Sanity check file name length
before allocating memory.  Move common section setup code.  Do
without bfd_tell to calculate section size.

Fix two typos in gdb_binary_search.h

I noticed a couple of typos in gdb_binary_search.h.  This fixes them.

gdbsupport/ChangeLog
2020-03-08  Tom Tromey  <tom@tromey.com>

* gdb_binary_search.h: Fix two typos.

[gdb/testsuite] Fix testing build_executable result

When running with target board unix/-feliminate-dwarf2-dups, we run into these
FAILs:
...
FAIL: gdb.cp/rvalue-ref-params.exp: print value of f1 on Child&& in f2
FAIL: gdb.cp/ref-params.exp: print value of f1 on Child in main
FAIL: gdb.cp/ref-params.exp: print value of f2 on Child in main
FAIL: gdb.cp/ref-params.exp: print value of f1 on Child& in f2
FAIL: gdb.cp/ref-params.exp: print mf1(MQ)
FAIL: gdb.cp/ref-params.exp: print mf2(MQ)
FAIL: gdb.cp/ref-params.exp: print f1(MQR)
FAIL: gdb.cp/ref-params.exp: print mf1(MQR)
FAIL: gdb.cp/ref-params.exp: print mf2(MQR)
...

This is due to comparing the result of build_executable to 1, while
build_executable returns either 0 for success, or -1 for failure.

Fix this by comparing with -1 instead.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.cp/ref-params.exp: Compare build_executable result with -1.
* gdb.cp/rvalue-ref-params.exp: Same.

[gdb] Support anonymous typedef generated by gcc -feliminate-dwarf2-dups

Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in
gcc-8).

When running tests with target board unix/-feliminate-dwarf2-dups, we run
into:
...
(gdb) PASS: gdb.ada/arraydim.exp: print m'length(3)
ptype global_3dim_for_gdb_testing^M
type = array (Unexpected type in ada_discrete_type_low_bound.^M
(gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing
...

The DWARF for the variable global_3dim_for_gdb_testing looks as follows:
...
 <0><824>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <825>   DW_AT_name        : src/gdb/testsuite/gdb.ada/arraydim/inc.c
 <1><832>: Abbrev Number: 2 (DW_TAG_array_type)
    <833>   DW_AT_type        : <0x874>
 <2><837>: Abbrev Number: 3 (DW_TAG_subrange_type)
    <838>   DW_AT_type        : <0x84a>
    <83c>   DW_AT_upper_bound : 0
 <2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type)
    <83e>   DW_AT_type        : <0x84a>
    <842>   DW_AT_upper_bound : 1
 <2><843>: Abbrev Number: 3 (DW_TAG_subrange_type)
    <844>   DW_AT_type        : <0x84a>
    <848>   DW_AT_upper_bound : 2
 <2><849>: Abbrev Number: 0
 <1><84a>: Abbrev Number: 4 (DW_TAG_typedef)
    <84b>   DW_AT_type        : <0x86d>
 <1><84f>: Abbrev Number: 0
 <0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit)
    <861>   DW_AT_name        : src/gdb/testsuite/gdb.ada/arraydim/inc.c
 <1><86d>: Abbrev Number: 6 (DW_TAG_base_type)
    <86e>   DW_AT_byte_size   : 8
    <86f>   DW_AT_encoding    : 7       (unsigned)
    <870>   DW_AT_name        : long unsigned int
 <1><874>: Abbrev Number: 7 (DW_TAG_base_type)
    <875>   DW_AT_byte_size   : 4
    <876>   DW_AT_encoding    : 5       (signed)
    <877>   DW_AT_name        : int
 <1><87b>: Abbrev Number: 8 (DW_TAG_variable)
    <87c>   DW_AT_name        : global_3dim_for_gdb_testing
    <882>   DW_AT_type        : <0x832>
    <886>   DW_AT_external    : 1
...

The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d.
Strictly speaking, the anonymous typedef is illegal DWARF, because a
DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name
of the typedef as it appears in the source program.

The DWARF reading code creates a corresponding type for this typedef, which
goes on to confuse the code handling arrays.

Rather than trying to support the type representing this anonymous typedef in
all the locations where it causes problems, fix this by treating the anonymous
typedef as a forwarder DIE in the DWARF reader.

Tested on x86_64-linux, with target boards unix and
unix/-feliminate-dwarf2-dups.

This fixes ~85 failures for unix/-feliminate-dwarf2-dups.

gdb/ChangeLog:

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

* dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder
DIE.

Remove some obsolete comments

While working on complex number support, I found a couple of
apparently obsolete coments.  This removes them.

2020-03-07  Tom Tromey  <tom@tromey.com>

* valops.c (value_literal_complex): Remove obsolete comment.
* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
comment.

Re: Add support for a ".file 0" directive if supporting DWARF 5 or higher.

Fixes a fail on hppa64-hp-hpux, where anything in the first column is
a label.

* testsuite/gas/elf/dwarf-5-file0.s: Don't start directives in
first column.

binutils: doc: move artifacts back to MAINTAINERCLEANFILES

In commit 2b44a6a237 (" binutils: doc: make `make clean` clean more
things"), I moved the doc build artifacts to MOSTLYCLEANFILES, which
made them get removed by "make clean".

Because generating binutils.info requires makeinfo, and we do not want
to require makeinfo when building from the tarball, binutils.info should
not get removed by "make clean" (otherwise, it won't be included in the
tarball).

And to be consistent with other projects (e.g. ld and gas), we also want
to ship the built man pages in the tarball.

This patch puts back all these in MAINTAINERCLEANFILES, so that they are
bundled in the tarball, and only cleaned if you use "make
maintainer-clean".

Tested by building a source release and confirming they are present.

binutils/ChangeLog:

PR 25491
* doc/Makefile.am: Rename MOSTLYCLEANFILES to MAINTAINERCLEANFILES.
* doc/Makefile.in: Re-generate.

Automatic date update in version.in

Pass thread_info pointer to various inferior control functions

[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ]

I noticed that some functions in infcmd and infrun call each other and
all call inferior_thread, while they could just get the thread_info
pointer from their caller.  That means less calls to inferior_thread, so
less reliance on global state, since inferior_thread reads
inferior_ptid.

The paths I am unsure about are:

  - fetch_inferior_event calls...
  - step_command_fsm::should_stop calls...
  - prepare_one_step

and

 - process_event_stop_test calls...
 - set_step_info

Before this patch, prepare_one_step gets the thread pointer using
inferior_thread.  After this patch, it gets it from the
execution_control_state structure in fetch_inferior_event.  Are we sure
that the thread from the execution_control_state structure is the same
as the one inferior_thread would return?  This code path is used when a
thread completes a step, but the user had specified a step count (e.g.
"step 5") so we decide to do one more step.  It would be strange (and
even a bug I suppose) if the thread in the ecs structure in
fetch_inferior_event was not the same thread that is prepared to stepped
by prepare_one_step.  So I believe passing the ecs thread is fine.

The same logic applies to process_event_stop_test calling
set_step_info.

gdb/ChangeLog:

* infrun.h: Forward-declare thread_info.
(set_step_info): Add thread_info parameter, add doc.
* infrun.c (set_step_info): Add thread_info parameter, move doc
to header.
* infrun.c (process_event_stop_test): Pass thread to
set_step_info call.
* infcmd.c (set_step_frame): Add thread_info pointer, pass it to
set_step_info.
(prepare_one_step): Add thread_info parameter, pass it to
set_step_frame and prepare_one_step (recursive) call.
(step_1): Pass thread to prepare_one_step call.
(step_command_fsm::should_stop): Pass thread to
prepare_one_step.
(until_next_fsm): Pass thread to set_step_frame call.
(finish_command): Pass thread to set_step_info call.

Don't try to get the TIB address without an inferior

The target_get_tib_address call always fails in this case, and there is an
error when changing the program with the file command:

(gdb) file allocer64.exe
Reading symbols from allocer64.exe...
You can't do that when your target is `exec'

Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.

gdb/ChangeLog:

2020-03-06  Hannes Domani  <ssbssa@yahoo.de>

* windows-tdep.c (windows_solib_create_inferior_hook):
Check if inferior is running.

Add support for a ".file 0" directive if supporting DWARF 5 or higher.

PR 25614
* dwarf2dbg.c (dwarf2_directive_filename): Allow a file number of
0 if the dwarf_level is 5 or more.  Complain if a filename follows
a file 0.
* testsuite/gas/elf/dwarf-5-file0.s: New test.
* testsuite/gas/elf/dwarf-5-file0.d: New test driver.
* testsuite/gas/elf/elf.exp: Run the new test.

PR 25612
* config/tc-ia64.h (DWARF2_VERISION): Fix typo.
* doc/as.texi: Fix another typo.

[gdb/testsuite] Fix "text file busy" errors with cc-with-tweaks.exp

When using target board cc-with-gdb-index.exp and running tests in parallel,
we run into:
...
gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \
  build/gdb/testsuite/gdb.sh: Text file busy
...

The problem is that because of the parallel test run, gdb.sh is created for
every single test-case, and eventually gdb.sh is overwritten while being
executed.

Fix this by creating gdb.sh only once.

Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a
serial and parallel -j 5 test run.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (tentative_rename, cached_file): New proc.
* boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.

Add support for --dwarf-[3|4|5] to assembler command line.

PR 25612
* as.c (dwarf_level): Define.
(show_usage): Add --gdwarf-3, --gdwarf-4 and --gdwarf-5.
(parse_args): Add support for the new options.
as.h (dwarf_level): Prototype.
* dwarf2dbg.c (DWARF2_VERSION): Use dwarf_level as default version
value.
* config/tc-ia64.h (DWARF2_VERISION): Update definition.
(DWARF2_LINE_VERSION): Remove definition.
* doc/as.texi: Document the new options.

[gdb,testsuite,doc,NEWS] Fix "the the".

Replace "the the" by "the".

gdb/ChangeLog:

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

* NEWS: Fix "the the".
* ctfread.c: Same.

gdb/doc/ChangeLog:

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

* gdb.texinfo: Fix "the the".

gdb/testsuite/ChangeLog:

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

* README: Fix "the the".
* gdb.base/dprintf.exp: Same.

[gdb] Remove trailing "done" after "Reading symbols from" message

Using verbose, we get some detail on symbol loading:
...
$ gdb a.out -iex "set verbose on"
Reading symbols from a.out...
Reading in symbols for /home/vries/hello.c...done.
(gdb)
...

And using debug symtab-create, much more detail:
...
$ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1"
Reading symbols from a.out...
Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ...
Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out.
Done reading minimal symbols.
Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ...
Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S.
Created psymtab 0x353e4e0 for module init.c.
Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S.
Created psymtab 0x353e5e0 for module /home/vries/hello.c.
Created psymtab 0x35bd530 for module elf-init.c.
Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c.
done.
(gdb)
...

The "Created compunit symtab" message gets inbetween the "Reading in symbols"
and the trailing "done.". [ Strictly speaking this is a regression since
commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the
same problem happens when using -batch before this commit. ]

Fix this by removing the trailing "done." altogether, such that we get:
...
Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...
Created compunit symtab 0x359dd20 for hello.c.
(gdb)
...

[ Alternatively, we could fix this emitting a "Done reading in symbols" line
or some such, like is done for minimal symbols.  See above. ]

[ Note: Removing the trailing "done." for the "Reading symbols from" message
was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ]

Build and reg-tested on x86_64-linux.

gdb/ChangeLog:

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

* psymtab.c (psymtab_to_symtab): Don't print "done.".

gdbserver/gdbsupport: Add .dir-locals.el file

Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.

I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.

We now have three copies of this file, which are all identical.  It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.

Some options considered were:

  1. Use symlinks to only have one copy of the file.  This was
  rejected as not all targets support symlinks in the way.

  2. Have two of the .dir-locals.el files contain some mechanism by
  which the third copy of the file is sourced.  Though this would, in
  theory, be possible, it would involve some advanced Emacs scripting,
  would be fragile, and a maintenance burdon.

  3. Move the .dir-locals up into top level src/ directory, then use
  Emacs dir-locals directory pattern matching to only apply the rules
  for the three directories we care about.  The problem is that each
  directory has to be listed separately, so we still end up having to
  duplicate all the rules.

In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now.  This was all discussed
in this mailing list thread:

  https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html

The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:

  https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header

gdb/ChangeLog:

* .dir-locals.el: Add a comment referencing the other copies of
this file.

gdbserver/ChangeLog:

* .dir-locals.el: New file.

gdbsupport/ChangeLog:

* .dir-locals.el: New file.

Stop the assembler from complaining that the input and output files are the same, if neither of them are regular files.

PR 25572
* as.c (main): Allow matching input and outputs when they are
not regular files.

Fix an abort triggered when objcopy is used to set the "share" section flag on an ELF section.

binutils* objcopy.c (check_new_section_flags): New function.  Reject the
SEC_COFF_SHARED flag if the target is not a COFF binary.
(copy_object): Call check_new_section_flags.
(setup_section): Likewise.
* doc/binutils.texi (objcopy): Add a note that the 'share' section
flag cannot be applied to ELF binaries.

bfd * elf.c (_bfd_elf_set_section_contents): Replace call to abort
with error messages and failure return values.

x86: reduce amount of various VCVT* templates

Presumably as a result of various changes over the last several months,
and - for some of them - with a generalization of logic in
match_mem_size() plus mirroring of this generalization into the
broadcast handling logic of check_VecOperands(), various register-only
templates can be foled into their respective memory forms. This in
particular then also allows dropping a few more instances of IgnoreSize.

x86: drop/replace IgnoreSize

Even after commit dc2be329b950 ("i386: Only check suffix in instruction
mnemonic"), by which many of its uses have become unnecessary (some were
unnecessary even before), IgnoreSize is still used for various slightly
different purposes:
- to suppress emission of an operand size prefix,
- in Intel syntax mode to zap "derived" suffixes in certain cases and to
  skip certain checks of remaining "derived" suffixes,
- to suppress ambiguous operand size / missing suffix diagnostics,
- for prefixes to suppress the "stand-alone ... prefix" warning.
Drop entirely unnecessary ones and where possible also replace instances
by the more focused (because of having just a single purpose) NoRex64.

To further restrict when IgnoreSize is needed, also generalize the logic
when to skip a template because of a present or derived L or Q suffix,
by skipping immediate operands. Additionally consider mask registers and
VecSIB there.

Note that for the time being the attribute needs to be kept in place on
MMX/SSE/etc insns (but not on VEX/EVEX encoded ones unless an operand
template of them allows for only non-SIMD-register actuals) allowing for
Dword operands - the logic when to emit a data size prefix would need
further adjustment first.

Note also that the memory forms of {,v}pinsrw get their permission for
an L or Q suffix dropped. I can only assume that it being this way was a
cut-and-paste mistake from the register forms, as the latter
specifically have NoRex64 set, and the {,v}pextrw counterparts don't
allow these suffixes either.

Convert VexW= again to their respective VexW* on lines touched anyway.

x86: fold (supposed to be) identical code

The Q and L suffix exclusion checks in match_template() ought to be
(kept) in sync as far as their FPU and SIMD aspects go. This was
already violated by only the Q one checking for active broadcast.
Convert the code such that there'll be only one instance of the logic,
the more that subsequently the logic is liable to need further
refinement / extension. (The alternative would be to drop all SIMD-ness
from the L part, but it is in principle possible to enable all sorts of
SIMD support with just a pre-386 CPU, via suitable .arch directives.)

x86: don't accept FI{LD,STP,STTP}LL in Intel syntax mode

As of commit dc2be329b950 ("i386: Only check suffix in instruction
mnemonic") these have been accepted even with "qword ptr" operand size
specifier, but in 64-bit mode they're now wrongly having a REX prefix
(with REX.W set) emitted in this case. These aren't Intel syntax
mnemonics, so rather than fixing code generation, let's simply reject
them. As a result, the Qword attribute can then be dropped, too.

x86: replace NoRex64 on VEX-encoded insns

When the template specifies any of the possible VexW settings, we can
use this instead of a separate NoRex64 to suppress the setting of REX_W.
Note that this ends up addressing an inconsistency between VEX- and
EVEX-encoded VEXTRACTPS, VPEXTR{B,W}, and VPINSR{B,W} - while the former
avoided setting VEX.W, the latter pointlessly set EVEX.W when there is a
64-bit GPR operand. Adjust the testcase to cover both cases.

Convert VexW= to their respective VexW* on lines touched anyway.

x86: drop Rex64 attribute

It is almost entirely redundant with Size64, and the sole case (CRC32)
where direct replacement isn't possible can easily be taken care of in
another way.

x86: correct MPX insn w/o base or index encoding in 16-bit mode

Since 16-bit addressing isn't allowed, Disp32 needs to be forced; Disp16
fails to match the templates.

The SDM leaves open whether BNDC[LNU] with a GPR operand require an
operand size override; this aspect is therefore left untouched here.

x86: add missing IgnoreSize

For proper code generation in 16-bit mode (or to avoid the "same type of
prefix used twice" diagnostic there), IgnoreSize is needed on certain
templates allowing for just 32-(and maybe 64-)bit operands.

Beyond adding tests for the previously broken cases, also add ones for
the previously working cases where IgnoreSize is needed for the same
reason (leaving out MPX for now, as that'll require an assembler change
first). Some minor adjustments to tests get done such that re-use of the
same code for 16-bit code generation testing becomes easier.

x86: refine TPAUSE and UMWAIT

Allowing 64-bit registers is misleading here: Elsewhere these get allowed
when there's no difference between either variant, because of 32-bit
destination registers having their upper halves zeroed in 64-bit mode.
Here, however, they're source registers, and hence specifying 64-bit
registers would lead to the ambiguity of whether the upper 32 bits
actually matter.

Additionally, for proper code generation in 16-bit mode, IgnoreSize is
needed on both.

And finally, just like for e.g. MONITOR/MWAIT, add variants with all
input registers explicitly specified.

bfd: xtensa: fix PR ld/25630

bfd/
2020-03-05  Max Filippov  <jcmvbkbc@gmail.com>

* elf32-xtensa.c (shrink_dynamic_reloc_sections): Shrink dynamic
relocation sections for any removed reference to a dynamic symbol.

PR25637, objcopy : SIGSEGV in copy_object

PR 25637
* objcopy.c (filter_symbols): Correct rem_leading_char logic.

Automatic date update in version.in

Use std::string for 'psargs'.

fbsd_make_corefile_notes leaked the memory for psargs previously.

gdb/ChangeLog:

* fbsd-tdep.c (fbsd_make_corefile_notes): Use std::string for
psargs.

gdbsupport/configure.ac: source development.sh

[Commit message by Simon Marchi]

The GDB build in non-development mode (turn development to false in
bfd/development.sh if you want to try) is currently broken:

      CXXLD  gdb
    /home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:218: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
    /home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:220: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:2310: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
    /home/smarchi/src/binutils-gdb/gdb/gdbarch-selftests.c:168: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
    /home/smarchi/src/binutils-gdb/gdbsupport/selftest.cc:96: error: undefined reference to 'selftests::reset()'

This is because the gdbsupport configure script doesn't source
bfd/development.sh to set the development variable.  When $development
is unset, GDB_AC_SELFTEST defaults to enabling selftests.  I don't think
the macro was written with this intention in mind, it just happens to be
that way.

So gdbsupport thinks selftests are enabled, while gdb thinks they are
disabled.  gdbsupport compiles in code that calls selftests:: functions,
which are normally provided by gdb, but gdb doesn't provide them, hence
the undefined references.

Fix this by sourcing bfd/development.sh in gdbsupport/configure.ac, so
that the development variable is set.

gdbsupport/ChangeLog:

        * configure.ac: Added call development.sh.
        * configure: Regenerate.

Add support for ELF files which contain multiple reloc sections which all target the same section.

* elf-bfd.h (struct elf_backend_data): Add new fields:
init_secondary_reloc_section, slurp_secondary_reloc_section,
write_secondary_reloc_section.
(_bfd_elf_init_secondary_reloc_section): Prototype.
(_bfd_elf_slurp_secondary_reloc_section): Prototype.
(_bfd_elf_write_secondary_reloc_section): Prototype.
* elf.c ( bfd_section_from_shdr): Invoke the new
init_secondary_reloc_section backend function, if defined, when a
second reloc section is encountered.
(swap_out_syms): Invoke the new symbol_section_index function, if
defined, when computing the section index of an OS/PROC specific
symbol.
(_bfd_elf_init_secondary_reloc_section): New function.
(_bfd_elf_slurp_secondary_reloc_section): New function.
(_bfd_elf_write_secondary_reloc_section): New function.
(_bfd_elf_copy_special_section_fields): New function.
* elfcode.h (elf_write_relocs): Invoke the new
write_secondary_relocs function, if defined, in order to emit
secondary relocs.
(elf_slurp_reloc_table): Invoke the new slurp_secondary_relocs
function, if defined, in order to read in secondary relocs.
* elfxx-target.h (elf_backend_copy_special_section_fields):
Provide a non-NULL default definition.
(elf_backend_init_secondary_reloc_section): Likewise.
(elf_backend_slurp_secondary_reloc_section): Likewise.
(elf_backend_write_secondary_reloc_section): Likewise.
(struct elf_backend_data elfNN_bed): Add initialisers for the new
fields.
        * configure.ac (score_elf32_[bl]e_vec): Add elf64.lo
        * configure: Regenerate.

gdb, gdbserver, gdbsupport: add .gitattributes files

Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.

The files specify cpp-style diffs for .h and .c files.  This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):

   @@ -379,7 +379,7 @@ public:
      struct target_waitstatus pending_follow;

      /* True if this thread has been explicitly requested to stop.  */
   -  int stop_requested = 0;
   +  bool stop_requested = 0;

      /* The initiating frame of a nexting operation, used for deciding
         which exceptions to intercept.  If it is null_frame_id no

Note that the context of the change shows up as 'public:'; not so
useful.  With the .gitattributes file, we get:

   @@ -379,7 +379,7 @@ class thread_info : public refcounted_object
      struct target_waitstatus pending_follow;

      /* True if this thread has been explicitly requested to stop.  */
   -  int stop_requested = 0;
   +  bool stop_requested = 0;

      /* The initiating frame of a nexting operation, used for deciding
         which exceptions to intercept.  If it is null_frame_id no

The context is successfully shown as 'class thread_info'.

This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders.  An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though.  I opted for the more conservative approach.

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

* .gitattributes: New file.

gdbserver/ChangeLog:
2020-03-05  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* .gitattributes: New file.

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

* .gitattributes: New file.

Reduce --warn-section-align output

PR 25570
* ldlang.c (lang_size_sections_1): Don't report changes on
second and subsequent iterations that make no change in
alignment from that already reported.

[gdb/testsuite] Update maint.exp for string cache

When running gdb.base/maint.exp, I see:
...
FAIL: gdb.base/maint.exp: maint print statistics
...

This is due to commit be1e3d3eab "Introduce objfile::intern", which replaces
the macro and filename caches with a string cache.

Update maint.exp accordingly.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/maint.exp: Update "main print statistics" expected output.

PR25629, objcopy : SIGSEGV in filter_symbols

PR 25629
* objcopy.c (filter_symbols): Don't segfault on NULL
prefix_symbols_string.

RISC-V: Support assembler modifier %got_pcrel_hi.

gas/
* config/tc-riscv.c: Support the modifier %got_pcrel_hi.
* doc/c-riscv.texi: Add documentation.
* testsuite/gas/riscv/no-relax-reloc.d: Add test case for the new
modifier %got_pcrel_hi.
* testsuite/gas/riscv/no-relax-reloc.s: Likewise.
* testsuite/gas/riscv/relax-reloc.d: Likewise.
* testsuite/gas/riscv/relax-reloc.s: Likewise.

RISC-V: Add description for RISC-V Modifiers to as doc.

gas/
* doc/c-riscv.texi (relocation modifiers): Add documentation.
(RISC-V-Formats): Update the section name from "Instruction Formats"
to "RISC-V Instruction Formats".

Large memory allocation reading fuzzed 64-bit archive

This patch adds a sanity check for the size of an armap.

* archive64.c (_bfd_archive_64_bit_slurp_armap): Check parsed_size
against file size before allocating memory.  Use bfd_alloc rather
than bfd_zalloc for carsym/strings memory.

Automatic date update in version.in

Introduce objfile::intern

This introduces a string cache on the per-BFD object, replacing the
macro and filename caches.  Both of these caches just store strings,
so this consolidation by itself saves a little memory (about the size
of a bcache per objfile).

Then this patch switches some allocations on the objfile obstack to
use this bcache instead.  This saves more space; and turns out to be a
bit faster as well.

Here are the before and after "maint time" + "maint space" results of
"file ./gdb":

    Command execution time: 4.664021 (cpu), 4.728518 (wall)
    Space used: 39190528 (+29212672 for this command)

    Command execution time: 4.216209 (cpu), 4.107023 (wall)
    Space used: 36667392 (+26689536 for this command)

The main interface to the string cache is a new pair of overloaded
methods, objfile::intern.

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

* symmisc.c (print_symbol_bcache_statistics)
(print_objfile_statistics): Update.
* symfile.c (allocate_symtab): Use intern.
* psymtab.c (partial_symtab::partial_symtab): Use intern.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache,
macro_cache>: Remove.
<string_cache>: New member.
(struct objfile) <intern>: New methods.
* elfread.c (elf_symtab_read): Use intern.
* dwarf2/read.c (fixup_go_packaging): Intern package name.
(dwarf2_compute_name, dwarf2_physname)
(create_dwo_unit_in_dwp_v1, create_dwo_unit_in_dwp_v2): Intern
names.
(guess_partial_die_structure_name): Update.
(partial_die_info::fixup): Intern name.
(dwarf2_canonicalize_name): Change parameter to objfile.  Intern
name.
(dwarf2_name): Intern name.  Update.
* buildsym.c (buildsym_compunit::get_macro_table): Use
string_cache.

Make "gnutarget" const

I noticed that gnutarget was not "const".  Since writing through this
pointer would probably be a bug, I think it ought to be.  This patch
makes the change.

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

* jit.c (bfd_open_from_target_memory): Make "target" const.
* corefile.c (gnutarget): Now const.
* gdbcore.h (gnutarget): Now const.

PR25570, ld duplicate "warning: changing start of section"

Note that because we should report a signed delta from the previous
VMA it isn't possible to use ngettext.  ngettext only supports
unsigned long values.  So byte/bytes goes from the message.

PR 25570
* ldlang.c (lang_sizing_iteration): New static var.
(lang_size_sections_1): Warn about no memory region only on first
iteration.  Warn about changing start address on first iteration
then any delta from that on subsequent iterations.  Report a signed
delta.
(one_lang_size_sections_pass): Increment lang_sizing_iteration.

Implement debugging of WOW64 processes

For WOW64 processes, the Wow64* variants of SuspendThread,
GetThreadContext, SetThreadContext, and GetThreadSelectorEntry have to
be used instead.
And instead of EnumProcessModules, EnumProcessModulesEx with
LIST_MODULES_32BIT is necessary.

gdb/ChangeLog:

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

* NEWS: Mention support for WOW64 processes.
* amd64-windows-nat.c (amd64_mappings): Rename and remove static.
(amd64_windows_segment_register_p): Remove static.
(_initialize_amd64_windows_nat): Update.
* configure.nat <windows> (NATDEPFILES): Add i386-windows-nat.o.
* i386-windows-nat.c (context_offset): Update.
(i386_mappings): Rename and remove static.
(i386_windows_segment_register_p): Remove static.
(_initialize_i386_windows_nat): Update.
* windows-nat.c (STATUS_WX86_BREAKPOINT): New macro.
(STATUS_WX86_SINGLE_STEP): New macro.
(EnumProcessModulesEx): New macro.
(Wow64SuspendThread): New macro.
(Wow64GetThreadContext): New macro.
(Wow64SetThreadContext): New macro.
(Wow64GetThreadSelectorEntry): New macro.
(windows_set_context_register_offsets): Add static.
(windows_set_segment_register_p): Likewise.
(windows_add_thread): Adapt for WOW64 processes.
(windows_fetch_one_register): Likewise.
(windows_nat_target::fetch_registers): Likewise.
(windows_store_one_register): Likewise.
(display_selector): Likewise.
(display_selectors): Likewise.
(handle_exception): Likewise.
(windows_continue): Likewise.
(windows_nat_target::resume): Likewise.
(windows_add_all_dlls): Likewise.
(do_initial_windows_stuff): Likewise.
(windows_nat_target::attach): Likewise.
(windows_get_exec_module_filename): Likewise.
(windows_nat_target::create_inferior): Likewise.
(windows_xfer_siginfo): Likewise.
(_initialize_loadable): Initialize Wow64SuspendThread,
Wow64GetThreadContext, Wow64SetThreadContext,
Wow64GetThreadSelectorEntry and EnumProcessModulesEx.
* windows-nat.h (windows_set_context_register_offsets):
Remove declaration.
(windows_set_segment_register_p): Likewise.
(i386_windows_segment_register_p): Add declaration.
(amd64_windows_segment_register_p): Likewise.

Generate a warning in the ARM assembler if a PC-relative thumb load instruction is detected in a section with insufficient alignment.

* config/tc-arm.c (md_apply_fix): Warn if a PC-relative load is
detected in a section which does not have at least 4 byte
alignment.
* testsuite/gas/arm/armv8-ar-it-bad.s: Add alignment directive.
* testsuite/gas/arm/ldr-t.s: Likewise.
* testsuite/gas/arm/sp-pc-usage-t.s: Likewise.
* testsuite/gas/arm/sp-pc-usage-t.d: Finish test at end of
disassembly, ignoring any NOPs that may have been inserted because
of section alignment.
* testsuite/gas/arm/ldr-t.d: Likewise.

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

Revert the change since it breaks existing behavior of "info registers"
for some architectures. At least AArch64 and ARM are impacted by this change.

gdb/ChangeLog:

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

Revert aa66aac47b4dd38f9524ddb5546c08cc09930d37 due to regressions
in "info registers" for AArch64/ARM.

The change caused "info registers" to not print GPR's.

gdb/ChangeLog:

2020-02-01  Shahab Vahedi  <shahab@synopsys.com>

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

[gdb/doc] Remove trailing done from "Reading symbols from" lines

Since commit 3453e7e409 'Clean up "Reading symbols" output' we no longer print
"done." after the "Reading symbols from" message:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb)
...

Update docs accordingly.

Build on x86_64-linux.

gdb/doc/ChangeLog:

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

* gdb.texinfo: Remove trailing "done." in "Reading symbols from" lines.
* python.texi: Same.

gdb.fortran: Allow Flang kind printing in fortran testing

In lib/fortran.exp, in the helper function fortran_int4, kind
parameter is expected to be printed as (kind=4) for the LLVM
Fortran compiler, Flang along with gfortran.  And in the helper
function fortran_int8 kind parameter is expected to be printed
as (kind=8).  But for the Flang compiler default kind is not
printed and non default kind is printed differently than gfortran
as below.
  integer(kind=4) => integer
  integer(kind=8) => integer*8
  real(kind=4) => real
  real(kind=8) => double precision
  complex(kind=4) => complex
  logical(kind=4) => logical
  character(kind=1) => character
This commit adds support for printing of kind parameter for the
Flang.  There should be no change when testing with gfortran.

Note: The current patch overrides earlier patch with below details.
  commit c3b149eb7697b376df1b3a47d0102afda389ee6d
  Author Alok Kumar Sharma (alokkumar.sharma@amd.com)
Earlier patch was incomplete and based on assumption that flang
should be changed to dump a type with kind like the way gfortan does.
Later it was realized that the way flang dumps this info is not
incorrect but different. And changes in gdb test framework are
finalized.

gdb/testsuite/ChangeLog:

* lib/fortran.exp (fortran_int4): Handle flang kind printing.
(fortran_int8): Likewise.
(fortran_real4): Likewise.
(fortran_real8): Likewise.
(fortran_complex4): Likewise.
(fortran_logical4): Likewise.
(fortran_character1): Likewise.

x86: support VMGEXIT

It has been publicly documented for quite some time, albeit not in the
"General-Purpose and System Instructions" volume:
https://www.amd.com/system/files/TechDocs/24593.pdf.

Revert "PR25570, ld duplicate "warning: changing start of section""

This reverts commit 91114f7583fac8fdf57c58a1f632839da62e43da.

PR25570, ld duplicate "warning: changing start of section"

PR 25570
* ldlang.c (lang_size_sections_1): Delay emitting non-fatal
errors/warnings until final pass.
* ldexp.c (fold_name): Likewise.

sh_addralign inconsistent with sh_addr

The ELF gABI says in part of sh_addralign:  "The value of sh_addr must
be congruent to 0, modulo the value of sh_addralign."

* elf.c (elf_fake_sections): Ensure sh_addralign is such that
sh_addr mod sh_addalign is zero.

Call cleanup on bfd_check_format_matches error exit

* format.c (bfd_check_format_matches): Call cleanup on error exit.

objcopy: Fix for pr19005 on machines with more than one octet per byte.

On machines with more than one octet per byte, objcopy fills only a part
of the gap between sections.

* objcopy.c (copy_object): Convert from bytes to octets for
--gap-fill and --pad-to.

Automatic date update in version.in