nds32_elf_get_relocated_section_contents

nds32_elf_get_relocated_section_contents uses nds32_get_section_contents
to read sections contents, but nds32_get_section_contents has the wrong
behaviour as it calls bfd_malloc_and_get_section.  That function always
mallocs its output buffer, whereas get_relocated_section_contents must
support an already allocated buffer.

bfd/
* elf32-nds32.c (nds32_get_section_contents): Replace
bfd_malloc_and_get_section with bfd_get_full_section_contents.
(nds32_elf_relax_delete_blanks): Init contents.
(nds32_elf_relax_section, nds32_relax_fp_as_gp): Likewise.
binutils/
* testsuite/binutils-all/compress.exp: Remove nds32 xfails.
* testsuite/binutils-all/objdump.exp: Likewise.

alpha_ecoff_get_relocated_section_contents

Use bfd_get_full_section_contents and tidy the start of this function
to match current generic get_relocated_section_contents.

* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Use
bfd_get_full_section_contents.

Automatic date update in version.in

Modernise _bfd_elf_mips_get_relocated_section_contents

In particular, bfd_get_full_section_contents rather than
bfd_get_section_contents so that compressed sections are handled
properly.

Necessary for mips if objdump is to not cache debug sections.

* elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents): Apply
all fixes to bfd_generic_get_relocated_section_contents since this
function was split out.

objdump: don't add an extra entry to syms array

Space for a NULL is there in every backend bfd_get_symtab_upper_bound
or bfd_get_dynamic_symtab_upper_bound when the symbol count is non-zero,
and placed as a terminator by bfd_canonicalize_symtab.  Many backends
even return a single NULL entry array for zero symbol count, and while
there are a few that return a NULL array for no symbols, that case is
handled fine in objdump.  So don't have objdump add yet another NULL
entry.

* objdump.c (slurp_symtab): Don't add an extra entry for NULL
to the symbol array.
(slurp_dynamic_symtab): Likewise.
(dump_bfd): Formatting.  Copy terminating NULL from extra_syms.

Regen for binutils/aclocal.m4 change

* Makefile.in: Regenerate.
* doc/Makefile.in: Regenerate.

ld testsuite: change unresolved to unsupported/fail

"unresolved" as a test result means runtest returns an error, which
can be confusing when there is no apparent error unless you look in
.log files.  In particular many tests are skipped without reporting an
error if no target C compiler is found, but if a target C compiler is
found but won't compile a testcase for some reason we used to mark the
test as unresolved.  Which is no more worthy of an error than when
lacking a C compiler entirely.

* testsuite/ld-cdtest/cdtest.exp,
* testsuite/ld-checks/checks.exp,
* testsuite/ld-elf/binutils.exp,
* testsuite/ld-elf/compress.exp,
* testsuite/ld-elf/dwarf.exp,
* testsuite/ld-elf/exclude.exp,
* testsuite/ld-elf/frame.exp,
* testsuite/ld-elf/indirect.exp,
* testsuite/ld-elf/linux-x86.exp,
* testsuite/ld-elf/sec-to-seg.exp,
* testsuite/ld-elf/tls_common.exp,
* testsuite/ld-elfcomm/elfcomm.exp,
* testsuite/ld-elfvers/vers.exp,
* testsuite/ld-elfvsb/elfvsb.exp,
* testsuite/ld-elfweak/elfweak.exp,
* testsuite/ld-ifunc/binutils.exp,
* testsuite/ld-mips-elf/mips-elf-flags.exp,
* testsuite/ld-misc/defsym.exp,
* testsuite/ld-mn10300/mn10300.exp,
* testsuite/ld-plugin/lto.exp,
* testsuite/ld-plugin/plugin.exp,
* testsuite/ld-scripts/align.exp,
* testsuite/ld-scripts/assert.exp,
* testsuite/ld-scripts/crossref.exp,
* testsuite/ld-scripts/defined.exp,
* testsuite/ld-scripts/extern.exp,
* testsuite/ld-scripts/log2.exp,
* testsuite/ld-scripts/map-address.exp,
* testsuite/ld-scripts/phdrs.exp,
* testsuite/ld-scripts/phdrs2.exp,
* testsuite/ld-scripts/script.exp,
* testsuite/ld-scripts/section-flags.exp,
* testsuite/ld-scripts/sizeof.exp,
* testsuite/ld-scripts/weak.exp,
* testsuite/ld-selective/selective.exp,
* testsuite/ld-sh/sh.exp,
* testsuite/ld-shared/shared.exp,
* testsuite/ld-srec/srec.exp,
* testsuite/ld-tic6x/tic6x.exp,
* testsuite/ld-undefined/undefined.exp,
* testsuite/ld-undefined/weak-undef.exp,
* testsuite/lib/ld-lib.exp: Don't use unresolved except after
perror.  Instead report "unsupported" or "fail".

Automatic date update in version.in

sim: testsuite: push $arch out to targets

This is needed to move to automake & its dejagnu-provided logic,
and eventually by the unified sim logic.  The $arch is used only
to figure out which `run` program to use when running tests, and
as we move to a single top-level build, we can delete this and
use sim/run directly.

sim: rx: mitigate fread warning

Current toolchains warn about unused result from fread, so mitigate
the edge case if fread returns short data.  It's not great, but it
gets things building again.

sim: switch to AC_CONFIG_MACRO_DIRS

Rather than hand maintain m4 includes in various autotool files,
use AC_CONFIG_MACRO_DIRS to declare the relevant search paths.
This simplifies the code, makes it more robust, and cleans out
unused logic from configure.

sim: common: delete unused aclocal.m4

This was missed when we deleted the common/configure build logic.

config/debuginfod: do not include pkg.m4 directly

Any code using AC_DEBUGINFOD from this dir is using -I../config when
running aclocal, so an explicit include on pkg.m4 is unnecessary:
aclocal will find the pkg.m4 in this dir just as easily.  This is
seen in the only two dirs that use AC_DEBUGINFOD (binutils & gdb)
as their aclocal.m4 already has m4_include on config m4 files.

The include as written only works if aclocal is run on a dir that is
at the same level of config/.  Any other depth will fail.
./
|-- config/
|-- binutils/    # works
|-- gdb/         # works
`-- sim/         # works
    `-- <port>/  # fails

It fails even if AC_DEBUGINFOD itself isn't used:
sim/bfin/ $ aclocal -I../../config
aclocal-1.15: error: ../../config/debuginfod.m4:8: file '../config/pkg.m4' does not exist

Automatic date update in version.in

Add stdio support to gdbreplay

I've been using gdbreplay to help debug an intermittent failure, and I
wanted it to be a little simpler to use.  This patch adds support for
"-" as the "address" argument.  With this patch you can do:

    (gdb) target remote | gdbreplay logfile -

... and not have to start gdbreplay in a separate shell.

2021-02-12  Tom Tromey  <tromey@adacore.com>

* gdbreplay.cc (remote_desc): Remove.
(remote_desc_in, remote_desc_out): New globals.
(remote_close): Update.
(remote_open): Handle "-".
(remote_open): Update.
(logchar): Log to stderr.
(expect, play): Update.

[gdb/threads] Fix lin_thread_get_thread_signals for glibc 2.28

When running test-case gdb.threads/create-fail.exp on openSUSE Factory
(with glibc version 2.32) I run into:
...
(gdb) continue
Continuing.
[New Thread 0x7ffff7c83700 (LWP 626354)]
[New Thread 0x7ffff7482700 (LWP 626355)]
[Thread 0x7ffff7c83700 (LWP 626354) exited]
[New Thread 0x7ffff6c81700 (LWP 626356)]
[Thread 0x7ffff7482700 (LWP 626355) exited]
[New Thread 0x7ffff6480700 (LWP 626357)]
[Thread 0x7ffff6c81700 (LWP 626356) exited]
[New Thread 0x7ffff5c7f700 (LWP 626358)]
[Thread 0x7ffff6480700 (LWP 626357) exited]
pthread_create: 22: Invalid argument

Thread 6 "create-fail" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7ffff5c7f700 (LWP 626358)]
0x00007ffff7d87695 in clone () from /lib64/libc.so.6
(gdb) FAIL: gdb.threads/create-fail.exp: iteration 1: run till end
...
The problem is that glibc-internal signal SIGCANCEL is not recognized by gdb.

There's code in check_thread_signals that is supposed to take care of that,
but it's not working because this code in lin_thread_get_thread_signals has
stopped working:
...
  /* NPTL reserves the first two RT signals, but does not provide any
     way for the debugger to query the signal numbers - fortunately
     they don't change.  */
  sigaddset (set, __SIGRTMIN);
  sigaddset (set, __SIGRTMIN + 1);
...

Since glibc commit d2dc5467c6 "Filter out NPTL internal signals (BZ #22391)"
(first released as part of glibc 2.28), a sigaddset with a glibc-internal
signal has no other effect than setting errno to EINVALID.

Fix this by eliminating the usage of sigset_t in check_thread_signals and
lin_thread_get_thread_signals.

The same problem was observed on Ubuntu 20.04.

Tested on x86_64-linux, openSUSE Factory.
Tested on aarch64-linux, Ubuntu 20.04 and Ubuntu 18.04.

gdb/ChangeLog:

2021-02-12  Tom de Vries  <tdevries@suse.de>

PR threads/26228
* linux-nat.c (lin_thread_get_thread_signals): Remove.
(lin_thread_signals): New static var.
(lin_thread_get_thread_signal_num, lin_thread_get_thread_signal):
New function.
* linux-nat.h (lin_thread_get_thread_signals): Remove.
(lin_thread_get_thread_signal_num, lin_thread_get_thread_signal):
Declare.
* linux-thread-db.c (check_thread_signals): Use
lin_thread_get_thread_signal_num and lin_thread_get_thread_signal.

Minor constification in gdbreplay

I noticed a spot in gdbreplay where "const" could be used.

2021-02-12  Tom Tromey  <tromey@adacore.com>

* gdbreplay.cc (remote_open): Constify.

Change the readelf and objdump programs so that they will automatically follow links to separate debug info files.

* configure.ac (follow-debug-links): Add option to enable or
disable the following of debug links by default.  Set the
default for the option to be 'follow'.
* dwarf.c (do_follow_links): Initialise with DEFAULT_FOR_FOLLOW_LINKS.
(dwarf_select_sections_by_names): Add no-follow-links option.
(dwarf_select_sections_by_letter): Add 'N' option.
* objdump.c (usage): Add conditional text describing the
follow links option.
(slurp_symtab): Ensure that there is a NULL entry at the end
of the symbol table.
(slurp_dynamic_symtab): Likewise.
(dump_bfd): When extending the symbol table, ensure that there
is still a NULL entry at the end.
* readelf.c (usage): Add conditional text describing the
follow links option.
* doc/binutils.texi: Update documentation for objcopy and
readelf.
* doc/debug.options.texi: Update documentation of the
follow-links option.
* config.in: Regenerate.
* configure: Regenerate.
* testsuite/binutils-all/compress.exp: Add the -WN option to
objdump command lines that are not expecting to follow links.
* testsuite/binutils-all/readelf.exp: Add the
--debug-dump=no-follow-links option to tests that are not
expecting to follow debug links.

gas * testsuite/gas/mach-o/sections-1.d: Stop automatic debug link
        following.
* testsuite/gas/xgate/insns-dwarf2.d: Likewise.

ld * testsuite/ld-elf/sec64k.exp: Stop readelf from automatically
following debug links.

gdb/fortran: support ALLOCATED builtin

Add support for the ALLOCATED keyword to the Fortran expression
parser.

gdb/ChangeLog:

* f-exp.y (f77_keywords): Add allocated.
* f-lang.c (evaluate_subexp_f): Handle UNOP_FORTRAN_ALLOCATED.
(operator_length_f): Likewise.
(print_subexp_f): Likewise.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* std-operator.def (UNOP_FORTRAN_ALLOCATED): New operator.

gdb/testsuite/ChangeLog:

* gdb.fortran/allocated.exp: New file.
* gdb.fortran/allocated.f90: New file.

binutils testsuite: replace unresolved with unsupported

You'd think "unresolved" would be correct for an objcopy test when the
assembler refuses to assemble one of our source files.  After all, the
test of objcopy hasn't been run.  However, "unresolved" results in
runtest returning with an error status.  If instead we report
"unsupported", runtest returns success.  Which is a little less
confusing to a user who doesn't see any errors reported unless they
look in log files.

* testsuite/binutils-all/objcopy.exp: Report "unsupported" when
gas or ld fails to build a testcase rather than "unresolved".
Report "fail" when readelf returns an error status rather than
"unresolved".
* testsuite/binutils-all/ar.exp: Likewise.
* testsuite/binutils-all/compress.exp: Likewise.
* testsuite/binutils-all/readelf.exp: Likewise.

binutils test pr25662: don't use single character labels

This fixes the test for z80, which predefine register symbols "a" and
"c" among others.

* testsuite/binutils-all/pr25662.s: Replace "a" with "aaa" and
"c" with "ccc" labels.

gas testsuite: adjust recently added tests for hppa

Some hppa gas targets treat anything starting in the first column as a
label, so directives can't start there.  Also, binutils_assemble and
run_dump_test cleverly edit test source to suit the hppa .comm
directive which has a different syntax to most targets.  The editing
means we can't match source file names in dumps.  Finally, hppa gas
complains if instructions are emitted without a ".text" or similar
directive.

* testsuite/gas/all/pr27381.err: Don't match source file name.
* testsuite/gas/all/pr27381.s: Don't start directive in first column.
* testsuite/gas/all/pr27384.err: Don't match source file name.
Adjust line number.
* testsuite/gas/all/pr27384.s: Add ".text" directive.
* testsuite/gas/elf/pr27355.err: Don't match source file name.

[binutils] Fix typo in comment in dwarf.h

Fix typo DW_AT_GNU_FORM_addr_index -> DW_FORM_GNU_addr_index.

binutils/ChangeLog:

2021-02-12  Tom de Vries  <tdevries@suse.de>

* dwarf.h (debug_info): Fix typo in comment.

[binutils] Fix printing of .debug_str_offsets

With exec:
...
$ clang -gdwarf-5 ./src/gdb/testsuite/gdb.dwarf2/fission-mix*.c
...
we have:
...
$ readelf -w a.out
  ...
Contents of the .debug_str_offsets section:

    Length: 0x24
    Version: 0x5
       Index   Offset [String]
           0      1d0 clang version 10.0.1
           1      1e6 src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c
           2      213 /home/vries/gdb_versions/devel
           3      232 bar
           4      236 x
           5       61 int
           6      238 s
           7      23a func2
           8       2c ild/BUILD/glibc-2.26/csu
           9        5 sdeps/x86_64/start.S
          10      1d0 clang version 10.0.1
          11      240 src/gdb/testsuite/gdb.dwarf2/fission-mix.c
          12      213 /home/vries/gdb_versions/devel
          13      26b foo
          14      236 x
          15       61 int
          16      238 s
          17      26f func
          18      274 main
          19      279 arg
...

The section consists of two parts, one for each CU, each with a header, but
the printing only reads the first header as a header, and prints the second
header as:
...
           8       2c ild/BUILD/glibc-2.26/csu
           9        5 sdeps/x86_64/start.S
...

Fix this in display_debug_str_offsets such that we have:
...
           6      238 s
           7      23a func2
    Length: 0x2c
    Version: 0x5
       Index   Offset [String]
           0      1d0 clang version 10.0.1
           1      240 src/gdb/testsuite/gdb.dwarf2/fission-mix.c
...

binutils/ChangeLog:

2021-02-12  Tom de Vries  <tdevries@suse.de>

* dwarf.c (display_debug_str_offsets): Handle multiple sets of
entries.

[binutils] Print DWO ID

With exec:
...
$ gcc -gsplit-dwarf ~/hello.c -gdwarf-5
...
a dwarf-5 DW_UT_skeleton CU is generated, but the corresponding DWO ID is not
printed by readelf -wi.

Add this, such that we have:
....
   Compilation Unit @ offset 0xc7:
    Length:        0x31 (32-bit)
    Version:       5
    Unit Type:     DW_UT_skeleton (4)
    Abbrev Offset: 0x64
    Pointer Size:  8
+   DWO ID:        0x4756ae3ac4348f21
  <0><db>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
...

binutils/ChangeLog:

2021-02-12  Tom de Vries  <tdevries@suse.de>

* dwarf.c (process_debug_info): Print DWO ID.

Automatic date update in version.in

[gdb/symtab] Handle DW_FORM_strx in form_requires_reprocessing

When running test-case gdb.dwarf2/fission-mix.exp using gcc-11, I run into:
...
(gdb) file fission-mix^M
Reading symbols from fission-mix...^M
src/gdb/dwarf2/attribute.h:258: internal-error: \
  void attribute::set_unsigned_reprocess(ULONGEST): \
  Assertion `form_requires_reprocessing ()' failed.^M
...

This happens when calling set_unsigned_reprocess on an attribute with form
DW_FORM_strx.  The assert triggers because DW_FORM_strx is not listed in
form_requires_reprocessing.

Fix this by adding DW_FORM_strx in form_requires_reprocessing.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-11  Tom de Vries  <tdevries@suse.de>

PR symtab/27353
* dwarf2/attribute.c (attribute::form_requires_reprocessing):
Return true for DW_FORM_strx.

Fix two Fortran regressions

Luis pointed out that an earlier patch of mine caused two regressions
in gdb.fortran.  This patch fixes the problem.

Regression tested on x86-64 Fedora 32.

gdb/ChangeLog
2021-02-11  Tom Tromey  <tromey@adacore.com>

PR gdb/27383:
* parse.c (write_exp_symbol_reference): Write sym.block.

Remove ia64 from obsolete list

* config.bfd: Remove ia64 from obsolete list.

Revert "ia64: Check UNDEFWEAK_NO_DYNAMIC_RELOC"

This reverts commit db41f6eb5234ea3c74c1ce4798cf9923d4a45a98.

gdb/testsuite: remove old comment

In commit:

  commit e92c8eb86dcef673652644694c832c504cf9a9a9
  Date:   Tue Feb 9 15:46:13 2021 +0000

      gdb/fortran: add parser support for lbound and ubound

When I created the test gdb/testsuite/gdb.fortran/lbound-ubound.exp, I
copied the script from a different file and failed to delete the test
description comment at the top (even though I added a new
description).  Fixed in this commit.

gdb/testsuite/ChangeLog:

* gdb.fortran/lbound-ubound.exp: Remove old comment.

gdb: change 'maint info section' to use command options

The 'maintenance info sections' command currently takes a list of
filters on the command line.  It can also accept the magic string
'ALLOBJ' which acts more like a command line flag, telling the command
to print information about all objfiles.

The manual has this to say about the options and filters:

  ... In addition, 'maint info sections' provides the following
  command options (which may be arbitrarily combined): ...

Implying (to me at least) that I can do this:

  (gdb) maint info sections ALLOBJ READONLY

to list all the read-only sections from all currently loaded object
files.

Unfortunately, this doesn't work.  The READONLY filter will work, but
ALLOBJ will not be detected correctly.

It would be fairly simple to fix the ALLOBJ detection.  However, I
dislike this mixing of command options (ALLOBJ) with command data (the
filters, e.g. READONLY, etc).

As this is a maintenance command, so not really intended for end
users, I think we can be a little more aggressive in "fixing" the
option parsing.  So that's what I do in this commit.

The ALLOBJ mechanism is replaced with a real command
option (-all-objects).  The rest of the command operates just as
before.  The example above would now become:

  (gdb) maint info sections -all-objects READONLY

The manual has been updated, and I added a NEWS entry to document the
change.

gdb/ChangeLog:

* NEWS: Mention changes to 'maint info sections'.
* maint.c (match_substring): Return a bool, fix whitespace issue.
(struct single_bfd_flag_info): New struct.
(bfd_flag_info): New static global.
(match_bfd_flags): Return a bool, use bfd_flag_info.
(print_bfd_flags): Use bfd_flag_info.
(maint_print_section_info): Delete trailing whitespace.
(struct maint_info_sections_opts): New struct.
(maint_info_sections_option_defs): New static global.
(maint_info_sections_completer): New function.
(maintenance_info_sections): Use option parsing mechanism.
(_initialize_maint_cmds): Register command completer.

gdb/doc/ChangeLog:

* gdb.texinfo (Files): Update documentation for 'maint info
sections'.

gdb/testsuite/ChangeLog:

* gdb.base/maint-info-sections.exp: Update expected output, and
add additional tests. Again.

gdb: 'maint info sections' - handle the no executable case

The 'maint info sections' command is split into two blocks or work,
first if there's an executable then the sections from the executable,
and optionally all other loaded object files are printed.  Then all
the sections from any core file are printed.

I ran into a situation where (for various reasons) I wasn't using a
main executable.  Instead I connected to a remote target and used
add-symbol-file.  This allowed me to debug an image that was already
loaded on the remote system.

Unfortunately, when I tried to use 'maint info sections' I saw
nothing.  The reason is that the loop over all object files is hidden
behind a check that we have a main executable.

This commit removes this check and merges together some duplicate
code.  I also (I think) made the output of this command cleaner.

Here is the original output of 'maint info sections':

  Exec file:
      `/tmp/hello.x', file type elf64-x86-64.
   [0]      0x004002a8->0x004002c4 at 0x000002a8: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x004002c4->0x004002e8 at 0x000002c4: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...

And my modified output:

  Exec file: `/home/andrew/tmp/hello.x', file type elf64-x86-64.
   [0]      0x004002a8->0x004002c4 at 0x000002a8: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x004002c4->0x004002e8 at 0x000002c4: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...

The forced newline after 'Exec file: ' has been removed.  This is now
a wrap point (in case the filename is very long).

Here is the original output of 'maint info sections ALLOBJ':

  Exec file:
      `/tmp/hello.x', file type elf64-x86-64.
    Object file: /tmp/hello.x
   [0]      0x004002a8->0x004002c4 at 0x000002a8: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x004002c4->0x004002e8 at 0x000002c4: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...
    Object file: /lib64/ld-linux-x86-64.so.2
   [0]      0x7ffff7fd12a8->0x7ffff7fd12c8 at 0x000002a8: .note.gnu.property ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x7ffff7fd12c8->0x7ffff7fd12ec at 0x000002c8: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...

And my modified output:

  Exec file: `/tmp/hello.x', file type elf64-x86-64.
   [0]      0x004002a8->0x004002c4 at 0x000002a8: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x004002c4->0x004002e8 at 0x000002c4: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...
  Object file: `/lib64/ld-linux-x86-64.so.2', file type elf64-x86-64.
   [0]      0x7ffff7fd12a8->0x7ffff7fd12c8 at 0x000002a8: .note.gnu.property ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x7ffff7fd12c8->0x7ffff7fd12ec at 0x000002c8: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...

The executable now only gets a single header line.  The header line
for the additional object files is no longer indented as it was
before, and the line is laid out in a similar style to the main
executable line (with quotes and file type information).

And of course, the biggest change.  If GDB is started with no
executable, but then the user does 'add-symbol-file ....' followed by
'maint info sections ALLOBJ', previously they got nothing, now they
get:

  Object file: `/tmp/hello.x', file type elf64-x86-64.
   [0]      0x004002a8->0x004002c4 at 0x000002a8: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
   [1]      0x004002c4->0x004002e8 at 0x000002c4: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
   ...

gdb/ChangeLog:

* maint.c (print_bfd_section_info_maybe_relocated): Delete,
functionality merged into...
(maint_print_all_sections): ...this new function.
(maintenance_info_sections): Make use of maint_print_all_sections,
allow all objects to be printed even where there's no executable.

gdb/testsuite/ChangeLog:

* gdb.base/maint-info-sections.exp: Update expected output, and
add additional tests.

gdb/testsuite: split 'maint info sections' tests to a new file

The next couple of patches are going to add more tests for the 'maint
info sections' command.  Rather than try to jam these tests into the
already quite long gdb.base/maint.c, this commit moves all of the
tests for 'maint info sections' into a new file.

I've updated the tests to make use of some newer testsuite constructs,
like -wrap and $gdb_test_name for gdb_test_multiple, but otherwise the
tests should not have changed with this commit.

gdb/testsuite/ChangeLog:

* gdb.base/maint-info-sections.exp: New file, content is moved
from gdb.base/maint.exp and cleaned up to use latest testsuite
techniques.
* gdb.base/maint.exp: Tests moved out to
gdb.base/maint-info-sections.exp.

gdb: add obj_section function to bound_minimal_symbol

Add a new obj_section function to bound_minimal_symbol, this just
calls obj_section on the contained minimal_symbol passing in the
contained objfile.

This allows some minor code simplification in a few places.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* breakpoint.c (resolve_sal_pc): Make use of
bound_minimal_symbol::obj_section.
* maint.c (maintenance_translate_address): Likewise.
* minsyms.c (minimal_symbol_upper_bound): Likewise.
* minsyms.h (struct bound_minimal_symbol) <obj_section>: New
member function.
* printcmd.c (info_address_command): Make use of
bound_minimal_symbol::obj_section.

PR27294, avr OOM

PR 27294
* elf32-avr.c (avr_elf32_load_records_from_section): Use
bfd_malloc_and_get_section.  Use bfd_byte* vars and remove then
unnecessary casts.

PR27290, PR27293, PR27295, various avr objdump fixes

Adds missing sanity checks for avr device info note, to avoid
potential buffer overflows.  Uses bfd_malloc_and_get_section for
sanity checking section size.

PR 27290
PR 27293
PR 27295
* od-elf32_avr.c (elf32_avr_get_note_section_contents): Formatting.
Use bfd_malloc_and_get_section.
(elf32_avr_get_note_desc): Formatting.  Return descsz.  Sanity
check namesz.  Return NULL if descsz is too small.  Ensure
string table is terminated.
(elf32_avr_get_device_info): Formatting.  Add note_size param.
Sanity check note.
(elf32_avr_dump_mem_usage): Adjust to suit.

PR27291, integer overflow in bfd_get_section_contents

Makes the code a little more elegant too.  Note that the unsigned
overflow reported here is well defined so this patch doesn't fix any
real problem.

PR 27291
* section.c (bfd_get_section_contents): Avoid possible overflow
when range checking offset and count.
(bfd_set_section_contents): Likewise.

gdb: adjust comment in gdb.multi/multi-target.exp.tcl

I wanted to make this change before pushing the last patch but forgot to
amend before pushing.

Change-Id: I8e1f03ee0131c1e75973718e7835b39580a06054

Automatic date update in version.in

gdb/testsuite: use "set sysroot" in gdb.multi/multi-target.exp.tcl

The multi-target tests involve some inferiors using remote targets.  By
default, GDB uses target: as the sysroot, which makes it read loaded
libraries and their debug info through GDBserver.  This makes the tests
run slower than necessary.

Pass `-ex "set sysroot"` when launching GDB in these tests, so that GDB
always reads from its local file system.

On a system where I don't have debug info for libc, that reduces run
time for

    $ make check TESTS="gdb.multi/multi-target-*.exp"

from 1:15 to 0:45.

On this other system where debug info is installed though, it reduces it
from 13:00 to 1:45.

gdb/testsuite/ChangeLog:

* gdb.multi/multi-target.exp.tcl (setup): Add "set sysroot" to
GDBFLAGS.

Change-Id: I9d24f3def843472d35dfb5667c12d70ae1d7e984

gdb: Remove arm-symbianelf support

Since it has gone from bfd/.

* arm-symbian-tdep.c: Delete.
* NEWS: Mention arm-symbian removal.
* Makefile.in: Remove arm-symbian-tdep entries.
* configure.tgt: Remove arm*-*-symbianelf*.
* doc/gdb.texinfo: Remove mention of SymbianOS.
* osabi.c (gdb_osabi_names): Remove "Symbian".
* osabi.h (enum gdb_osabi): Remove GDB_OSABI_SYMBIAN.
* testsuite/gdb.base/ending-run.exp: Remove E32Main handling.
* testsuite/gdb.ada/catch_ex_std.exp: Remove arm*-*-symbianelf*
handling.
* testsuite/gdb.base/dup-sect.exp: Likewise.
* testsuite/gdb.base/long_long.exp: Likewise.
* testsuite/gdb.base/solib-weak.exp: Likewise.
* testsuite/gdb.guile/scm-section-script.exp: Likewise.
* testsuite/gdb.python/py-section-script.exp: Likewise.
* testsuite/lib/dwarf.exp: Likewise.
* testsuite/lib/gdb.exp: Likewise.

Re: Remove arm-symbianelf

gas/
* NEWS: Mention arm-symbianelf removal.
ld/
* NEWS: Mention arm-symbianelf removal.

[binutils] Handle absolute DW_AT_dwo_name

With an exec:
...
$ pwd
/home/vries/tmp
$ gcc /home/vries/tmp/src/hello.c -gsplit-dwarf -c \
  -o /home/vries/tmp/obj/hello.o
...
I get:
...
$ readelf -w obj/hello.o > READELF
readelf: Warning: Unable to load dwo file: \
  /home/vries/tmp//home/vries/tmp/obj/hello.dwo
...

The dwo file name is listed here:
...
    <20>   DW_AT_GNU_dwo_name: /home/vries/tmp/obj/hello.dwo
    <24>   DW_AT_comp_dir    : /home/vries/tmp
...

The standard states about the DW_AT_dwo_name attribute:
...
value is a null-terminated string containing the full or relative path name
(relative to the value of the DW_AT_comp_dir attribute, see below) of the
object file that contains the full compilation unit.
...

So, readelf shouldn't try to prefix an absolute path with DW_AT_comp_dir.

Fix this in load_dwo_file by handling the absolute path case.

binutils/ChangeLog:

2021-02-10  Tom de Vries  <tdevries@suse.de>

PR binutils/27391
* dwarf.c (load_dwo_file): Handle case that name is absolute path.

gdb/fortran: add parser support for lbound and ubound

Add support for the LBOUND and UBOUND built in functions to the
Fortran expression parser.

Both support taking one or two arguments.  A single argument, which
must be an array, returns an array containing all of the lower or
upper bound data.

When passed two arguments, the second argument is the dimension being
asked about.  In this case the result is a scalar containing the lower
or upper bound just for that dimension.

Some examples of usage taken from the new test:

  # Given:
  #   integer, dimension (-8:-1,-10:-2) :: neg_array
  #
  (gdb) p lbound (neg_array)
  $1 = (-8, -10)
  (gdb) p lbound (neg_array, 1)
  $3 = -8
  (gdb) p lbound (neg_array, 2)
  $5 = -10

gdb/ChangeLog:

* f-exp.y (UNOP_OR_BINOP_INTRINSIC): New token.
(exp): New pattern using UNOP_OR_BINOP_INTRINSIC.
(one_or_two_args): New pattern.
(f77_keywords): Add lbound and ubound.
* f-lang.c (fortran_bounds_all_dims): New function.
(fortran_bounds_for_dimension): New function.
(evaluate_subexp_f): Handle FORTRAN_LBOUND and FORTRAN_UBOUND.
(operator_length_f): Likewise.
(print_subexp_f): Likewise.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* std-operator.def (FORTRAN_LBOUND): Define.
(FORTRAN_UBOUND): Define.

gdb/testsuite/ChangeLog:

* gdb.fortran/lbound-ubound.F90: New file.
* gdb.fortran/lbound-ubound.exp: New file.

libctf: add missing header in BFD ELF check

Without this, GCC warns:

In file included from conftest.c:36:
../../libctf/../bfd/elf-bfd.h: In function 'bfd_section_is_ctf':
../../libctf/../bfd/elf-bfd.h:3089:10: warning: implicit declaration of function 'strncmp' [-Wimplicit-function-declaration]
 3089 |   return strncmp (name, ".ctf", 4) == 0 && (name[4] == 0 || name[4] == '.');
      |          ^~~~~~~
../../libctf/../bfd/elf-bfd.h:3089:33: warning: 'strncmp' argument 3 type is 'int' where 'long unsigned int' is expected in a call to built-in function declared without prototype [-Wbuiltin-declaration-mismatch]
 3089 |   return strncmp (name, ".ctf", 4) == 0 && (name[4] == 0 || name[4] == '.');
      |                                 ^
<built-in>: note: built-in 'strncmp' declared here

These warnings do not currently throw off the result of the configure
check, but it's better to squash them anyway.

libctf/ChangeLog
2021-02-03  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (ac_cv_libctf_bfd_elf): Include string.h.
* configure: Regenerated.

libctf: require a Tcl capable of try/catch to run tests

The run_native_host_cmd implementation in testsuite/lib/ctf-lib.exp
uses try/catch, which are new in Tcl 8.6.  Require a Tcl that knows
that try exists, as suggested by Jan Beulich.

libctf/ChangeLog
2021-02-03  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (EXPECT): Check for, in order to define...
(TCL_TRY): ... this, if Tcl supports try/catch.
* Makefile.am (TCL_TRY): Run the testsuite only if set.
* configure: Regenerated.
* Makefile.in: Likewise.

bfd, opcodes, libctf: support --with-included-gettext

Right now, these libraries hardwire -L../intl -lintl on a few fixed
platforms, which works fine on those platforms but on other platforms
leads to shared libraries that lack libintl_* symbols when configured
--with-included-gettext, and/or static libraries that contain libintl as
*another* static library.  If we instead use the LIBINTL variable
defined in ../intl/config.intl, this gives us the right thing on all
three classes of platform (gettext in libc, gettext in system libintl,
gettext in ../intl/libintl.a)..  This also means we can rip out some
Darwin-specific machinery from configure.ac and also simplify the Cygwin
side.

This also means that the libctf testsuite (and other places that include
libbfd, libopcodes or libctf) don't need to grow libintl dependencies
just on account of those libraries (though they still need such
dependencies if they themselves use gettext machinery).

bfd/ChangeLog
2021-02-03  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (SHARED_LIBADD): Remove explicit -lintl population in
favour of LIBINTL.
* configure: Regenerated.

libctf/ChangeLog
2021-02-02  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (CTF_LIBADD): Remove explicit -lintl population in
favour of LIBINTL.
* Makefile.am (libctf_nobfd_la_LIBADD): No longer explicitly
include $(LIBINTL).
(check-DEJAGNU): Pass down to tests as well.
* configure: Regenerated.
* Makefile.in: Likewise.

opcodes/ChangeLog
2021-02-04  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (SHARED_LIBADD): Remove explicit -lintl population in
favour of LIBINTL.
* configure: Regenerated.

intl: turn LIBINTL into -L / -l form

This variable currently refers directly, not to a .la file, but to an .a
file.  This produces wrong results when building into a library on some
platforms: so convert it to the general form "-L${top_builddir}../intl
-lintl ..." ... so that both libtool and non-libtool builds will always
do the right thing for both static and shared links.

intl/ChangeLog
2021-02-04  Nick Alcock  <nick.alcock@oracle.com>

* configure.ac (LIBINTL): Transform into -L/-lintl form.
* configure: Regenerate.

intl: always picify

libintl is included in several shared libraries (at least
libinproctrace.so and libctf.so): unconditionally picify with code
borrowed from libiberty configure.  (It's not performance-critical, so
don't bother making separate PIC and non-PIC libraries like libiberty
does.)

intl/ChangeLog
2021-02-02  Nick Alcock  <nick.alcock@oracle.com>

* aclocal.m4: include picflag.m4.
* configure.ac (PICFLAG): Add and substitute.
* Makefile.in (PICFLAG): New.
(COMPILE): Use it.
* configure: Regenerate.

intl: Unbreak intl build with bison 3 when no regeneration is needed [PR92008]

As Iain reported, my change broke the case when one has bison >= 3,
but make decides there is no reason to regenerate plural.c, unfortunately
that seems to be a scenario I haven't tested.  The problem is that
the pregenerated plural.c has been generated with bison 1.35, but when
config.h says HAVE_BISON3, the code assumes it is the bison3 variant.
What used to work fine is when one has bison >= 3 and plural.c has been
regenerated (e.g. do touch intl/plural.y and it will work), or when
one doesn't have any bison (then nothing is regenerated, but HAVE_BISON3
isn't defined either), or when one has bison < 3 and doesn't need to
regenerate, or when one has bison < 3 and it is regenerated.

The following patch fixes this, by killing the HAVE_BISON3 macro from
config.h, and instead remembering the fact whether plural.c has been created
with bison < 3 or bison >= 3 in a separate new plural-config.h header.
The way this works:
- user doesn't have bison
- user has bison >= 3, but intl/{plural-config.h,plural.c} aren't older than intl/plural.y
- user has bison < 3, but intl/{plural-config.h,plural.c} aren't older than intl/plural.y
pregenerated !USE_BISON3 plural.c and plural-config.h from source
dir is used, nothing in the objdir
- user has bison >= 3 and intl/plural.y is newer
Makefile generates plural.c and USE_BISON3 plural-config.h in the
objdir, which is then used in preference to srcdir copies
- user has bison < 3 and intl/plural.y is newer
Makefile generates plural.c and !USE_BISON3 plural-config.h in the
objdir, which is then used in preference to srcdir copies
I have tested all these cases and make all-yes worked in all the cases.
If one uses the unsupported ./configure where srcdir == objdir, I guess
(though haven't tested) that it should still work, just it would be nice
if such people didn't try to check in the plural{.c,-config.h} they have
regenerated.
What doesn't work, but didn't work before either (just tested gcc-9 branch
too) is when one doesn't have bison and plural.y is newer than plural.c.
Don't do that ;)

intl/ChangeLog
2020-04-16  Jakub Jelinek  <jakub@redhat.com>

PR bootstrap/92008
* configure.ac: Remove HAVE_BISON3 AC_DEFINE.
* Makefile.in (HEADERS): Add plural-config.h.
(.y.c): Also create plural-config.h.
(dcigettext.o loadmsgcat.o plural.o plural-exp.o): Also depend
on plural-config.h.
(plural-config.h): Depend on plural.c.
* plural-exp.h: Include plural-config.h.  Use USE_BISON3 instead
of HAVE_BISON3.
* plural.y: Use USE_BISON3 instead of HAVE_BISON3.
* configure: Regenerated.
* plural.c: Regenerated.
* config.h.in: Regenerated.
* plural-config.h: Generated.

intl: Allow building both with old bison and bison >= 3 [PR92008]

bison 3 apparently made a backwards incompatible change, dropped
YYLEX_PARAM/YYPARSE_PARAM support and instead needs %param or %lex-param
and %parse-param.  Furthermore, there is no easy way to conditionalize
on bison version in the *.y files.
While e.g. glibc bumped bison requirement and just has the bison 3
compatible version, Richi said there are still systems with older bison
where we want to build gcc.

So, this patch instead determines during configure bison version, and
depending on that when building plural.c (if building it at all) tweaks
what is passed over to bison if needed.

Tested with both bison 3 and bison 1.35, in each case with reconfiguring
intl and building with make all-yes (as in my setup intl isn't normally
used).

intl/ChangeLog
2020-04-16  Jakub Jelinek  <jakub@redhat.com>

PR bootstrap/92008
* configure.ac: Add check for bison >= 3, AC_DEFINE HAVE_BISON3
and AC_SUBST BISON3_YES and BISON3_NO.
* Makefile.in (.y.c): Prefix $(YACC) invocation with @BISON3_NO@,
add @BISON3_YES@ prefixed rule to adjust the *.y source using sed
and adjust output afterwards.
* plural-exp.h (PLURAL_PARSE): If HAVE_BISON3 is defined, use
struct parse_args * type for arg instead of void *.
* plural.y: Add magic /* BISON3 ... */ comments with bison >= 3
directives.
(YYLEX_PARAM, YYPARSE_PARAM): Don't define if HAVE_BISON3 is defined.
(yylex, yyerror): Adjust prototypes and definitions if HAVE_BISON3
is defined.
* plural.c: Regenerated.
* config.h.in: Regenerated.
* configure: Regenerated.

gdb: delete SYMBOL_SECTION and MSYMBOL_SECTION macros

Delete two more symbol/section related macros.  This time it's
SYMBOL_SECTION and MSYMBOL_SECTION.

As with general_symbol_info::m_name it is not currently possible to
make general_symbol_info::m_section private as general_symbol_info
must remain a POD type.

But other than failing to make the new m_section private, this change
does what you'd expect, adds a get and set member function and updates
all users to use the new functions instead of the previous wrapper
macros.

There should be no user visible change after this commit.

gdb/ChangeLog:

* coff-pe-read.c (add_pe_forwarded_sym): Make use of section_index
and set_section_index member functions where appropriate.
* coffread.c (coff_symtab_read): Likewise.
(process_coff_symbol): Likewise.
* ctfread.c (set_symbol_address): Likewise.
* dwarf2/read.c (add_partial_symbol): Likewise.
(var_decode_location): Likewise.
* language.c: Likewise.
* minsyms.c (minimal_symbol_reader::record_full): Likewise.
(compact_minimal_symbols): Likewise.
(minimal_symbol_upper_bound): Likewise.
* objfiles.c (relocate_one_symbol): Likewise.
* psympriv.h (partial_symbol::obj_section): Likewise.
(partial_symbol::address): Likewise.
* psymtab.c (partial_symtab::add_psymbol): Likewise.
* stabsread.c (scan_file_globals): Likewise.
* symmisc.c (dump_msymbols): Likewise.
* symtab.c (general_symbol_info::obj_section): Likewise.
(fixup_section): Likewise.
(get_msymbol_address): Likewise.
* symtab.h (general_symbol_info::section): Rename to...
(general_symbol_info::m_section): ...this.
(general_symbol_info::set_section_index): New member function.
(general_symbol_info::section_index): Likewise.
(SYMBOL_SECTION): Delete.
(MSYMBOL_VALUE_ADDRESS): Make use of section_index and
set_section_index member functions where appropriate.
(MSYMBOL_SECTION): Delete.
(symbol::symbol): Update to initialize 'm_section'.
* xcoffread.c (read_xcoff_symtab): Make use of set_section_index.
(process_xcoff_symbol): Likewise.

gdb: Delete SYMBOL_OBJ_SECTION and MSYMBOL_OBJ_SECTION

Replace the two macros SYMBOL_OBJ_SECTION and MSYMBOL_OBJ_SECTION with
a member function on general_symbol_info.

There should be no user visible change after this commit.

gdb/ChangeLog:

* breakpoint.c (resolve_sal_pc): Replace SYMBOL_OBJ_SECTION and
MSYMBOL_OBJ_SECTION.
* findvar.c (language_defn::read_var_value): Likewise.
* infcmd.c (jump_command): Likewise.
* linespec.c (minsym_found): Likewise.
* maint.c (maintenance_translate_address): Likewise.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Likewise.
(minimal_symbol_upper_bound): Likewise.
* parse.c (find_minsym_type_and_address): Likewise.
(operator_check_standard): Likewise.
* printcmd.c (info_address_command): Likewise.
* symmisc.c (dump_msymbols): Likewise.
(print_symbol): Likewise.
* symtab.c (general_symbol_info::obj_section): Define new
function.
(fixup_symbol_section): Replace SYMBOL_OBJ_SECTION.
(find_pc_sect_compunit_symtab): Likewise.
(find_function_start_sal): Likewise.
(skip_prologue_sal): Replace SYMBOL_OBJ_SECTION and
MSYMBOL_OBJ_SECTION.
* symtab.h (struct general_symbol_info) <obj_section>: Declare new
function.
(SYMBOL_OBJ_SECTION): Delete.
(MSYMBOL_OBJ_SECTION): Delete.

[binutils] Handle presence of both .debug_ranges and .debug_rnglists

With exec:
...
$ g++ src/gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section
...
I run into:
...
$ readelf -w a.out > READELF
readelf: Error: Invalid range list entry type 126
readelf: Error: Invalid range list entry type 60
...

The executable contains both a .debug_rnglists section (for CU
cpexprs.cc) and a .debug_ranges section (for other CUs, like crti.S).  But
when executing display_debug_ranges for say, section .debug_rnglists it also
tries to use the range list references related to section .debug_ranges.

Fix this by filtering out the .debug_range references when handling
.debug_rnglists and vice versa.

binutils/ChangeLog:

2021-02-10  Tom de Vries  <tdevries@suse.de>

PR binutils/27371
* dwarf.c (display_debug_ranges): Filter range lists according to
section.

[gdb/testsuite] Fix tcl ERROR in gdb_load_no_complaints

In commit cf2b2075299 "[gdb/symtab] Fix element type modification in
read_array_type" I factored out new proc with_complaints out of proc
gdb_load_no_complaints, but when fixing a rebase conflict pre-commit I made a
mistake in gdb_load_no_complaints that is now causing:
...
ERROR: tcl error sourcing dw2-ranges-psym.exp.
ERROR: can't read "save": no such variable
    while executing
"gdb_test_no_output "set complaints $save" """
    (procedure "gdb_load_no_complaints" line 14)
    invoked from within
"gdb_load_no_complaints $binfile"
...

Fix this by removing the offending line.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-02-10  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (gdb_load_no_complaints): Remove unnecessary
"Restore saved setting of complaints".

Remove debugging code accidentally included with the fix for PR 27384

* listing.c (buffer_line): Remove debugging code accidentally
included with the fix for PR 27384.

Fix typo in stap_parse_argument_conditionally

This fixes a typo in an error message in
stap_parse_argument_conditionally.

gdb/ChangeLog
2021-02-09  Tom Tromey  <tom@tromey.com>

* stap-probe.c (stap_parse_argument_conditionally): Fix typo.

Automatic date update in version.in

[gdb/symtab] Fix element type modification in read_array_type

When running test-case gdb.fortran/function-calls.exp with target board
unix/gdb:debug_flags=-gdwarf-5, I run into:
...
(gdb) PASS: gdb.fortran/function-calls.exp: \
  p derived_types_and_module_calls::pass_cart(c)
p derived_types_and_module_calls::pass_cart_nd(c_nd)^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \
  (c=<error reading variable: Cannot access memory at address 0xc>) at \
  function-calls.f90:130^M
130             pass_cart_nd = ubound(c%d,1,4)^M
The program being debugged was signaled while in a function called from GDB.^M
GDB has restored the context to what it was before the call.^M
To change this behavior use "set unwindonsignal off".^M
Evaluation of the expression containing the function^M
(derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M
(gdb) FAIL: gdb.fortran/function-calls.exp: p
...

The problem originates in read_array_type, when reading a DW_TAG_array_type
with a dwarf-5 DW_TAG_generic_subrange child.  This is not supported, and the
fallout of this is that rather than constructing a new array type, the code
proceeds to modify the element type.

Fix this conservatively by issuing a complaint and bailing out in
read_array_type when not being able to construct an array type, such that we
have:
...
(gdb) maint expand-symtabs function-calls.f90^M
During symbol reading: unable to find array range \
  - DIE at 0xe1e [in module function-calls]^M
During symbol reading: unable to find array range \
  - DIE at 0xe1e [in module function-calls]^M
(gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \
  (PRMS: symtab/27388)
...

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-09  Tom de Vries  <tdevries@suse.de>

PR symtab/27341
* dwarf2/read.c (read_array_type): Return NULL when not being able to
construct an array type.  Add assert to ensure that element_type is
not being modified.

gdb/testsuite/ChangeLog:

2021-02-09  Tom de Vries  <tdevries@suse.de>

PR symtab/27341
* lib/gdb.exp (with_complaints): New proc, factored out of ...
(gdb_load_no_complaints): ... here.
* gdb.fortran/function-calls.exp: Add test-case.

gdb: revert "gdb: unify parts of the Linux and FreeBSD core dumping code"

This reverts commit 82a1fd3a4935fe665cf08bc6820942c4a091184c.

It was pointed out:

  https://sourceware.org/pipermail/gdb-patches/2021-February/175750.html

that commit 82a1fd3a4935 caused GDB to have an unconditional
dependency on ELF specific parts of BFD.  What this means is that if
GDB and BFD are built for a non-elf target then there will be
undefined symbol references within GDB.

The right solution isn't immediately obvious.  So rather than rush a
fix in I'm reverting this commit for now, and will bring it back once
I have a good solution.

gdb/ChangeLog:

* gcore.c (struct gcore_collect_regset_section_cb_data): Delete.
(gcore_collect_regset_section_cb): Delete.
(gcore_collect_thread_registers): Delete.
(gcore_build_thread_register_notes): Delete.
(gcore_find_signalled_thread): Delete.
* gcore.h: Remove 'gdbsupport/gdb_signals.h' include and delete
'gdbarch' and 'thread_info' declarations.
(gcore_build_thread_register_notes): Delete declaration.
(gcore_find_signalled_thread): Likewise.
* fbsd-tdep.c: Remove 'gcore.h' include.
(struct fbsd_collect_regset_section_cb_data): New struct.
(fbsd_collect_regset_section_cb): New function.
(fbsd_collect_thread_registers): New function.
(struct fbsd_corefile_thread_data): New struct.
(fbsd_corefile_thread): New function.
(fbsd_make_corefile_notes): Call FreeBSD specific code.
* linux-tdep.c: Remove 'gcore.h' include.
(struct linux_collect_regset_section_cb_data): New struct.
(linux_collect_regset_section_cb): New function.
(linux_collect_thread_registers): New function.
(linux_corefile_thread): Call Linux specific code.
(find_signalled_thread): New function.
(linux_make_corefile_notes): Call find_signalled_thread.

[testsuite] Don't use 'testfile' before 'standard_testfile'.

While running tests on arm-none-eabi, I noticed following errors in some
gdb.threads tests.

ERROR: can't read "testfile": no such variable

These were being caused by ${testfile} being used before 'standard_testfile'
which sets it. This patch just moves standard_testfile before the use.

2021-02-09  Abid Qadeer  <abidh@codesourcery.com>

gdb/testsuite/ChangeLog:

* gdb.threads/signal-command-handle-nopass.exp: Call
'standard_testfile' before using 'testfile'.
* gdb.threads/signal-command-multiple-signals-pending.exp: Likewise.
* gdb.threads/signal-delivered-right-thread.exp: Likewise
* gdb.threads/signal-sigtrap.exp: Likewise

Avoid crash from coerce_unspec_val_to_type

With a certain Ada program, ada-lang.c:coerce_unspec_val_to_type can
cause a crash.  This function may copy a value, and in the particular
case in the crash, the new value's type is smaller than the original
type.  This causes coerce_unspec_val_to_type to create a lazy value --
but the original value is also not_lval, so later, when the value is
un-lazied, gdb asserts.

As with the previous patch, we believe there is a compiler bug here,
but it is difficult to reproduce, so we're not completely certain.

In the particular case we saw, the original value has record type, and
the record holds some variable-length arrays.  This leads to the
type's length being 0.  At the same time, the value is optimized out.

This patch changes coerce_unspec_val_to_type to handle an
optimized-out value correctly.

It also slightly restructures this code to avoid a crash should a
not_lval value wind up here.  This is a purely defensive change.

This change also made it clear that value_contents_copy_raw can now be
made static, so that is also done.

gdb/ChangeLog
2021-02-09  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (coerce_unspec_val_to_type): Avoid making lazy
not_lval value.
* value.c (value_contents_copy_raw): Now static.
* value.h (value_contents_copy_raw): Don't declare.

Avoid crash in resolve_dynamic_struct

resolve_dynamic_struct says:

  gdb_assert (type->num_fields () > 0);

However, a certain Ada program has a structure with no fields but with
a dynamic size, causing this assertion to fire.

It is difficult to be certain, but we think this is a compiler bug.
However, in the meantime this assertion does not seem to be checking
any kind of internal consistency; so this patch removes it.

gdb/ChangeLog
2021-02-09  Tom Tromey  <tromey@adacore.com>

* gdbtypes.c (resolve_dynamic_struct): Handle structure with no
fields.

[binutils] Handle DW_FORM_ref_sig8 in get_type_abbrev_from_form

When compiling an exec like this:
...
$ gcc -fdebug-types-section hello.c -gdwarf-5
...
we run into:
...
$ readelf -w a.out > READELF
readelf: Warning: Unexpected form 20 encountered whilst finding \
  abbreviation for type
...

Fix this by handling DW_FORM_ref_sig8 conservatively in
get_type_abbrev_from_form.

binutils/ChangeLog:

2021-02-09  Tom de Vries  <tdevries@suse.de>

PR binutils/27370
* dwarf.c (get_type_abbrev_from_form): Handle DW_FORM_ref_sig8.

Add a sanity check of files include by .incbin.

PR 27381
* read.c (s_incbin): Check that the file to be included is a
regular, non-directory file.
* testsuite/gas/all/pr27381.s: New test source file.
* testsuite/gas/all/pr27381.d: New test control file.
* testsuite/gas/all/pr27381.err: Expected error output for the new test.
* testsuite/gas/all/gas.exp: Run the new test.

[binutils] Handle DW_UT_skeleton/split_compile in process_debug_info

With this exec:
...
$ gcc -gsplit-dwarf hello.c -gdwarf-5
...
we run into:
...
$ readelf -w a.out > READELF
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
...

Fix this by handling DW_UT_skeleton and DW_UT_split_compile in
process_debug_info.

Note that this just adds the parsing of DWO_id, but not yet any printing of
it.

Tested on x86_64-linux.

binutils/ChangeLog:

2021-02-09  Tom de Vries  <tdevries@suse.de>

PR binutils/27386
* dwarf.c (process_debug_info): Handling DW_UT_skeleton and
DW_UT_split_compile.

Remove arm-symbianelf

* configure.ac: Delete arm*-*-symbianelf* entry.
* configure: Regenerate.
bfd/
* config.bfd (arm*-*-symbianelf*): Move from obsolete to removed.
* configure.ac: Delete symbian entries.
* elf-bfd.h (enum elf_target_os): Delete is_symbian.
* elf32-arm.c: Remove symbian support.  Formatting.
* targets.c: Delete symbian entries.
* configure: Regenerate.
binutils/
* testsuite/lib/binutils-common.exp (supports_gnu_osabi): Remove
symbianelf.
gas/
* Makefile.am (TARG_ENV_HFILES): Remove config/te-symbian.h.
* config/tc-arm.c (elf32_arm_target_format): Remove TE_SYMBIAN
support.
* config/te-symbian.h: Delete.
* configure.tgt: Remove arm-*-symbianelf*.
* testsuite/gas/arm/arch4t-eabi.d: Don't mention symbianelf in
target selection.
* testsuite/gas/arm/arch4t.d: Likewise.
* testsuite/gas/arm/got_prel.d: Likewise.
* testsuite/gas/arm/mapdir.d: Likewise.
* testsuite/gas/arm/mapmisc.d: Likewise.
* testsuite/gas/arm/mapsecs.d: Likewise.
* testsuite/gas/arm/mapshort-eabi.d: Likewise.
* testsuite/gas/arm/thumb-eabi.d: Likewise.
* testsuite/gas/arm/thumb.d: Likewise.
* testsuite/gas/arm/thumbrel.d: Likewise.
* Makefile.in: Regenerate.
* po/POTFILES.in: Regenerate.
ld/
* Makefile.am (ALL_EMULATION_SOURCES): Remove earmsymbian.c.
Don't include symbian dep file.
* configure.tgt: Remove arm*-*-symbianelf* entry.
* emulparams/armsymbian.sh: Delete.
* ld.texi: Don't mention symbian.
* scripttempl/armbpabi.sc: Delete.
* testsuite/ld-arm/symbian-seg1.d: Delete.
* testsuite/ld-arm/symbian-seg1.s: Delete.
* testsuite/ld-arm/arm-elf.exp: Don't run symbian-seg1.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.

Prevent a bad .Psize expression from triggering a memory access violation.

PR 27384
* listing.c (listing_psize): Check the result of the width
expression before assigning it to paper_width.
* testsuite/gas/all/pr27384.s: New test source file.
* testsuite/gas/all/pr27384.d: New test control file.
* testsuite/gas/all/pr27384.err: Expected errors from new test.
* testsuite/gas/all/gas.exp: Run the new test.

Add a test for PR 27355 - where corrupt assembler .file directives could trigger a segmentation fault.

PR 27355
* testsuite/gas/elf/pr27355.s: New test source file.
* testsuite/gas/elf/pr27355.d: New test control file.
* testsuite/gas/elf/pr27355.err: Expected errors from new test.
* testsuite/gas/elf/elf.exp: Run the new test.

Automatic date update in version.in

opcodes: tic54x: namespace exported variables

The tic54x exports some fairly generic variable names that can
conflict with programs that use them, so put proper tic54x_
prefixes on all of them.

Build gdb.base/gnu-ifunc.exp with lazy binding

The test expects the ifunc resolver to run lazily, at a later stage.

Depending on the distro and toolchain configuration, this is not the
case. Some configurations use non-lazy binding and thus the ifunc resolver
resolves all the ifunc references very early in the process startup, before
main.

Ubuntu is one such case. It has switched its toolchains to pass -Wl,z,now by
default, since 16.04. This wasn't a problem before 20.04 (at least for
aarch64) because the toolchains did not support ifunc's.

Forcing lazy binding makes the test run as expected, as opposed to the 80 or
so failures it showed before the change.

Tested on aarch64-linux/x86_64-linux Ubuntu 20.04.

gdb/testsuite:

2021-02-08  Luis Machado  <luis.machado@linaro.org>

* gdb.base/gnu-ifunc.exp (build): Pass -Wl,z,lazy.

Fix an illegal memory access when parsing a corrupt assembler file.

PR 27355
* dwarf2dbg.c (allocate_filename_to_slot): Allocate the dirs array
if it has not already been created.

[gdb/testsuite] Use DW_FORM_ref_addr in gdb.dwarf2/enqueued-cu-base-addr.exp

When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-dwz, I get:
...
gdb compile failed, dwz: enqueued-cu-base-addr: \
  Couldn't find DIE at [100] referenced by DW_AT_type from DIE at [d8]
...

At 0xd8 we have DIE:
...
 <1><d8>: Abbrev Number: 3 (DW_TAG_variable)
    <d9>   DW_AT_name        : foo
    <dd>   DW_AT_type        : <0x100>
    <e1>   DW_AT_const_value : 1
...
referring to:
...
 <1><100>: Abbrev Number: 3 (DW_TAG_base_type)
    <101>   DW_AT_byte_size   : 4
    <102>   DW_AT_encoding    : 5       (signed)
    <103>   DW_AT_name        : int
...

The reference is inter-CU, but the used abbrev uses DW_FORM_ref4:
...
   3      DW_TAG_variable    [no children]
    DW_AT_name         DW_FORM_string
    DW_AT_type         DW_FORM_ref4
    DW_AT_const_value  DW_FORM_sdata
    DW_AT value: 0     DW_FORM value: 0
...
which is for intra-CU references.

Fix this by using a '%' instead of a ':' label prefix in the dwarf assembly.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-02-08  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/enqueued-cu-base-addr.exp: Fix inter-CU reference.

gdb: Do not interrupt atomic sequences for ARC

When stepping over thread-lock related codes (in uClibc), the inferior process
gets stuck and never manages to enter the critical section:

------8<-------
 1 size_t fwrite(const void * __restrict ptr, size_t size,
 2               size_t nmemb, register FILE * __restrict stream)
 3 {
 4     size_t retval;
 5     __STDIO_AUTO_THREADLOCK_VAR;
 6
 7 >   __STDIO_AUTO_THREADLOCK(stream);
 8
 9     retval = fwrite_unlocked(ptr, size, nmemb, stream);
10
11     __STDIO_AUTO_THREADUNLOCK(stream);
12
13     return retval;
14 }
------>8-------

Here, we are at line 7.  Using the "next" command leads no where.
However, setting a breakpoint on line 9 and issuing "continue" works.

Looking at the assembly instructions reveals that we're dealing with the
critical section entry code [1] that should never be interrupted, in this
case by the debugger's implicit breakpoints:

------8<-------
  ...
1 add_s   r0,r13,0x38
2 mov_s   r3,1
3 llock   r2,[r0]        <-.
4 brne.nt r2,0,14     --.  |
5 scond   r3,[r0]       |  |
6 bne     -10         --|--'
7 brne_s  r2,0,84     <-'
  ...
------>8-------

Lines 3 until 5 (inclusive) are supposed to be executed atomically.
Therefore, GDB should never (implicitly) insert a breakpoint on lines
4 and 5, else the program will try to acquire the lock again by jumping
back to line 3 and gets stuck in an infinite loop.

The solution is to make GDB aware of these patterns so it inserts
breakpoints after the sequence -- line 6 in this example.

[1]
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46
------8<-------
  ({ \
__typeof(oldval) prev; \
\
__asm__ __volatile__( \
"1: llock   %0, [%1] \n" \
" brne    %0, %2, 2f \n" \
" scond   %3, [%1] \n" \
" bnz     1b \n" \
"2: \n" \
: "=&r"(prev) \
: "r"(mem), "ir"(oldval), \
  "r"(newval) /* can't be "ir". scond can't take limm for "b" */\
: "cc", "memory"); \
\
prev; \
  })
------>8-------
"llock" (Load Locked) loads the 32-bit word pointed by the source
operand.  If the load is completed without any interruption or
exception, the physical address is remembered, in Lock Physical Address
(LPA), and the Lock Flag (LF) is set to 1.  LF is a non-architecturally
visible flag and is cleared whenever an interrupt or exception takes
place.  LF is also cleared (atomically) whenever another process writes
to the LPA.

"scond" (Store Conditional) will write to the destination address if
and only if the LF is set to 1.  When finished, with or without a write,
it atomically copies the LF value to ZF (Zero Flag).

These two instructions together provide the mechanism for entering a
critical section.  The code snippet above comes from uClibc:
-----------------------

v3 (after Tom's remarks[2]):
 handle_atomic_sequence()
  - no need to initialize the std::vector with "{}"
  - fix typo in comments: "conditial" -> "conditional"
  - add braces to the body of "if" condition because of the comment line
 arc_linux_software_single_step()
  - make the performance slightly more efficient by moving a few
    variables after the likely "return" point.

v2 (after Simon's remarks[3]):
- handle_atomic_sequence() gets a copy of an instruction instead of
  a reference.
- handle_atomic_sequence() asserts if the given instruction is an llock.

[2]
https://sourceware.org/pipermail/gdb-patches/2021-February/175805.html

[3]
https://sourceware.org/pipermail/gdb-patches/2021-January/175487.html

gdb/ChangeLog:

PR tdep/27369
* arc-linux-tdep.c (handle_atomic_sequence): New.
(arc_linux_software_single_step): Call handle_atomic_sequence().

gdb: return true in TuiWindow.is_valid only if TUI is enabled

If the user implements a TUI window in Python, and this window
responds to GDB events and then redraws its window contents then there
is currently an edge case which can lead to problems.

The Python API documentation suggests that calling methods like erase
or write on a TUI window (from Python code) will raise an exception if
the window is not valid.

And the description for is_valid says:

  This method returns True when this window is valid. When the user
  changes the TUI layout, windows no longer visible in the new layout
  will be destroyed. At this point, the gdb.TuiWindow will no longer
  be valid, and methods (and attributes) other than is_valid will
  throw an exception.

From this I, as a user, would expect that if I did 'tui disable' to
switch back to CLI mode, then the window would no longer be valid.
However, this is not the case.

When the TUI is disabled the windows in the TUI are not deleted, they
are simply hidden.  As such, currently, the is_valid method continues
to return true.

This means that if the users Python code does something like:

  def event_handler (e):
    global tui_window_object
    if tui_window_object->is_valid ():
      tui_window_object->erase ()
      tui_window_object->write ("Hello World")
  gdb.events.stop.connect (event_handler)

Then when a stop event arrives GDB will try to draw the TUI window,
even when the TUI is disabled.

This exposes two bugs.  First, is_valid should be returning false in
this case, second, if the user forgot to add the is_valid call, then I
believe the erase and write calls should be throwing an
exception (when the TUI is disabled).

The solution to both of these issues is I think bound together, as it
depends on having a working 'is_valid' check.

There's a rogue assert added into tui-layout.c as part of this
commit.  While working on this commit I managed to break GDB such that
TUI_CMD_WIN was nullptr, this was causing GDB to abort.  I'm leaving
the assert in as it might help people catch issues in the future.

This patch is inspired by the work done here:

  https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html

gdb/ChangeLog:

* python/py-tui.c (gdbpy_tui_window) <is_valid>: New member
function.
(REQUIRE_WINDOW): Call is_valid member function.
(REQUIRE_WINDOW_FOR_SETTER): New define.
(gdbpy_tui_is_valid): Call is_valid member function.
(gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead.
* tui/tui-data.h (struct tui_win_info) <is_visible>: Check
tui_active too.
* tui/tui-layout.c (tui_apply_current_layout): Add an assert.
* tui/tui.c (tui_enable): Move setting of tui_active earlier in
the function.

gdb/doc/ChangeLog:

* python.texinfo (TUI Windows In Python): Extend description of
TuiWindow.is_valid.

gdb/testsuite/ChangeLog:

* gdb.python/tui-window-disabled.c: New file.
* gdb.python/tui-window-disabled.exp: New file.
* gdb.python/tui-window-disabled.py: New file.

gdb/python: don't allow the user to delete window title attributes

There's a bug in the python tui API.  If the user tries to delete the
window title attribute then this will trigger undefined behaviour in
GDB due to a missing nullptr check.

gdb/ChangeLog:

* python/py-tui.c (gdbpy_tui_set_title): Check that the new value
for the title is not nullptr.

gdb/testsuite/ChangeLog:

* gdb.python/tui-window.exp: Add new tests.
* gdb.python/tui-window.py (TestWindow) <__init__>: Store
TestWindow object into global the_window.
<remote_title>: New method.
(delete_window_title): New function.

gdb/tui: don't add windows to global list from tui_layout:window::apply

This commit was inspired by this mailing list patch:

  https://sourceware.org/pipermail/gdb-patches/2021-January/174713.html

Currently, calling tui_layout_window::apply will add the window from
the layout object to the global tui_windows list.

Unfortunately, when the user runs the 'winheight' command, this calls
tui_adjust_window_height, which calls the tui_layout_base::adjust_size
function, which can then call tui_layout_base::apply.  The consequence
of this is that when the user does 'winheight' duplicate copies of a
window can be added to the global tui_windows list.

The original patch fixed this by changing the apply function to only
update the global list some of the time.

This patch takes a different approach.  The apply function no longer
updates the global tui_windows list.  Instead a new virtual function
is added to tui_layout_base which is used to gather all the currently
applied windows into a vector.  Finally tui_apply_current_layout is
updated to make use of this new function to update the tui_windows
list.

The benefits I see in this approach are, (a) the apply function now no
longer touches global state, this solves the immediate problem,
and (b) now that tui_windows is updated directly in the function
tui_apply_current_layout, we can drop the saved_tui_windows global.

gdb/ChangeLog:

* tui-layout.c (saved_tui_windows): Delete.
(tui_apply_current_layout): Don't make use of saved_tui_windows,
call new get_windows member function instead.
(tui_get_window_by_name): Check in tui_windows.
(tui_layout_window::apply): Don't add to tui_windows.
* tui-layout.h (tui_layout_base::get_windows): New member function.
(tui_layout_window::get_windows): Likewise.
(tui_layout_split::get_windows): Likewise.

gdb/testsuite/ChangeLog:

* gdb.tui/winheight.exp: Add more tests.

gdb/tui: restore delete of window objects

In commit:

  commit f237f998d1168139d599c550d54169cd8f94052d
  Date:   Mon Jan 25 18:43:19 2021 +0000

      gdb/tui: remove special handling of locator/status window

I accidentally remove a call to delete the tui window objects.  Now
every time GDB changes tui layout it is leaking windows.

gdb/ChangeLog:

* tui/tui-layout.c (tui_apply_current_layout): Restore the delete
of the window objects.

gdb/python: reformat an error string

While working on another patch I noticed an oddly formatted error
message in the Python code.

When 'set python print-stack message' is in effect then consider this
Python script:

  class TestCommand (gdb.Command):
      def __init__ (self):
          gdb.Command.__init__ (self, "test-cmd", gdb.COMMAND_DATA)
      def invoke(self, args, from_tty):
          raise RuntimeError ("bad")
  TestCommand ()

And this GDB session:

  (gdb) source path/to/python/script.py
  (gdb) test-cmd
  Python Exception <class 'RuntimeError'> bad:
  Error occurred in Python: bad

The line 'Python Exception <class 'RuntimeError'> bad:' doesn't look
terrible in this situation, the colon at the end of the first line
makes sense given the second line.

However, there are places in GDB where there is no second line
printed, for example consider this python script:

  def stop_listener (e):
      raise RuntimeError ("bad")
  gdb.events.stop.connect (stop_listener)

Then this GDB session:

  (gdb) file helloworld.exe
  (gdb) start
  Temporary breakpoint 1 at 0x40112a: file hello.c, line 6.
  Starting program: helloworld.exe

  Temporary breakpoint 1, main () at hello.c:6
  6   printf ("Hello World\n");
  Python Exception <class 'RuntimeError'> bad:
  (gdb) si
  0x000000000040112f 6   printf ("Hello World\n");
  Python Exception <class 'RuntimeError'> bad:

In this case there is no auxiliary information displayed after the
warning, and the line ending in the colon looks weird to me.

A quick survey of the code seems to indicate that it is not uncommon
for there to be no auxiliary information line printed, its not just
the one case I found above.

I propose that the line that currently looks like this:

  Python Exception <class 'RuntimeError'> bad:

Be reformatted like this:

  Python Exception <class 'RuntimeError'>: bad

I think this looks fine then in either situation.  The first now looks
like this:

  (gdb) test-cmd
  Python Exception <class 'RuntimeError'>: bad
  Error occurred in Python: bad

And the second like this:

  (gdb) si
  0x000000000040112f 6   printf ("Hello World\n");
  Python Exception <class 'RuntimeError'>: bad

There's just two tests that needed updating.  Errors are checked for
in many more tests, but most of the time the pattern doesn't care
about the colon.

gdb/ChangeLog:

* python/python.c (gdbpy_print_stack): Reformat an error message.

gdb/testsuite/ChangeLog:

* gdb.python/py-framefilter.exp: Update expected results.
* gdb.python/python.exp: Update expected results.

sim/rx: enable build with warnings

The rx simulator now has no build warnings.  Delete the call to
SIM_AC_OPTION_WARNINGS in configure.ac, the default yes will be
provided by SIM_AC_OUTPUT.

sim/rx/ChangeLog:

* configure: Regenerate.
* configure.ac (SIM_AC_OPTION_WARNINGS): Delete call.

sim/rx: avoid pointer arithmetic on void * pointers

Pointer arithmetic on void * pointers results in a GCC warning.  Avoid
the warning by casting the pointer to its actual type earlier in the
function.

sim/rx/ChangeLog:

* mem.c (mem_put_blk): Rename parameter, add cast from parameter
type to local type.  Remove cast later in the function.
(mem_get_blk): Likewise.
* mem.h (mem_put_blk): Rename parameter to match definition.
(mem_get_blk): Likewise.

sim/rx: add some missing includes

In load.c there's some GCC warnings about undefined
functions (bfd_get_elf_phdr_upper_bound and bfd_get_elf_phdrs).  To
get the declarations of these functions include 'elf-bfd.h'.  This
headers also pulls in other elf related headers, like 'elf/internal.h'
and 'elf/common.h', so these no longer need to be explicitly included
from load.c.

In trace.c and include for trace.h is missing, again this results in
GCC warnings for missing function declarations.

sim/rx/ChangeLog:

* load.c: Replace 'elf/internal.h' and 'elf/common.h' includes
with 'elf-bfd.h' include.
* trace.c: Add 'trace.h' include.

sim/rx: use PRIx64 in printf format string

Silence a GCC compiler warning by using PRIx64 in printf format string
instead of hard coded "llx".

sim/rx/ChangeLog:

* reg.c (trace_register_changes): Use PRIx64 in printf format
string.

sim/rx: move some variable declarations to the start of the block

For sim code variables still need to be declared at the start of the
enclosing block.  This silences a few GCC warnings.

sim/rx/ChangeLog:

* syscalls.c (rx_syscall): Move declaration of some variables to
the start of the enclosing block.
* trace.c (load_file_and_line): Likewise.

sim/rx: provide a format string for printf

Calling printf with the format being a non constant string results in
a GCC warning:

  warning: format not a string literal and no format arguments [-Wformat-nonliteral]

Provide a constant format string to printf in the few places this
warning is triggered.

sim/rx/ChangeLog:

* reg.c (fpsw2str): Provide a format string to printf.
(trace_register_changes): Likewise.

sim/rx: delete an unused function

This function is not used.

sim/rx/ChangeLog:

* err.c (execution_error_exit_all): Delete.

sim/rx: mark some functions as static

Some functions that should be marked static.

sim/rx/ChangeLog:

* fpu.c (check_exceptions): Make static.
* gdb-if.c (handle_step): Likewise.
* mem.c (mem_put_byte): Likewise.

sim/rx: fill in missing 'void' for empty argument lists

Ensure we have 'void' inside empty argument lists.  This was causing
several warnings for the rx simulator.

sim/rx/ChangeLog:

* cpu.h (trace_register_changes): Add void parameter type.
* err.c (ee_overrides): Likewise.
* mem.c (mem_usage_stats): Likewise.
(e): Likewise.
* reg.c (stack_heap_stats): Likewise.
* rx.c (pop): Likewise.
(poppc): Likewise.
(decode_opcode): Likewise.
* syscalls.c (arg): Likewise.

sim/rx: fix an issue where we try to modify a const string

While experimenting with switching on warnings for the rx simulator I
discovered this bug.  In sim_do_command we get passed a 'const char *'
argument.  We create a copy of this string to work with locally, but
then while processing this we accidentally switch back to reference
the original string.

sim/rx/ChangeLog:

* gdb-if.c (sim_do_command): Work with a copy of the command.

sim/rx: define sim_memory_map

The rx simulator doesn't define sim_memory_map and so fails to link
with GDB.  Define it now to return NULL, this can be extended later to
return an actual memory map if anyone wants this functionality.

sim/rx/ChangeLog:

* gdb-if.c (sim_memory_map): New function.

gdb/tui: fix issue with handling the return character

My initial goal was to fix our gdb/testsuite/lib/tuiterm.exp such that
it would correctly support (some limited) scrolling of the command
window.

What I observe is that when sending commands to the tui command window
in a test script with:

  Term::command "p 1"

The command window would be left looking like this:

  (gdb)
  (gdb) p 1$1 = 1
  (gdb)

When I would have expected it to look like this:

  (gdb) p 1
  $1 = 1
  (gdb)

Obviously a bug in our tuiterm.exp library, right???

Wrong!

Turns out there's a bug in GDB.

If in GDB I enable the tui and then type (slowly) the 'p 1\r' (the \r
is pressing the return key at the end of the string), then you do
indeed get the "expected" terminal output.

However, if instead I copy the 'p 1\r' string and paste it into the
tui in one go then I now see the same corrupted output as we do when
using tuiterm.exp.

It turns out the problem is that GDB fails when handling lots of input
arriving quickly with a \r (or \n) on the end.

The reason for this bug is as follows:

When the tui is active the terminal is in no-echo mode, so characters
sent to the terminal are not echoed out again.  This means that when
the user types \r, this is not echoed to the terminal.

The characters read in are passed to readline and \r indicates that
the command line is complete and ready to be processed.  However, the
\r is not included in readlines command buffer, and is NOT printed by
readline when is displays its buffer to the screen.

So, in GDB we have to manually spot the \r when it is read in and
update the display.  Printing a newline character to the output and
moving the cursor to the next line.  This is done in tui_getc_1.

Now readline tries to reduce the number of write calls.  So if we very
quickly (as in paste in one go) the text 'p 1' to readline (this time
with no \r on the end), then readline will fetch the fist character
and add it to its internal buffer.  But before printing the character
out readline checks to see if there's more input incoming.  As we
pasted multiple characters, then yes, readline sees the ' ' and adds
this to its buffer, and finally the '1', this too is added to the
buffer.

Now if at this point we take a break, readline sees there is no more
input available, and so prints its buffer out.

Now when we press \r the code in tui_getc_1 kicks in, adds a \n to the
output and moves the cursor to the next line.

But, if instead we paste 'p 1\r' in one go then readline adds 'p 1' to
its buffer as before, but now it sees that there is still more input
available.  Now it fetches the '\r', but this triggers the newline
behaviour, we print '\n' and move to the next line - however readline
has not printed its buffer yet!

So finally we end up on the next line.  There's no more input
available so readline prints its buffer, then GDB gets passed the
buffer, handles it, and prints the result.

The solution I think is to put of our special newline insertion code
until we know that readline has finished printing its buffer.  Handily
we know when this is - the next thing readline does is pass us the
command line buffer for processing.  So all we need to do is hook in
to the command line processing, and before we pass the command line to
GDB's internals we do all of the magic print a newline and move the
cursor to the next line stuff.

Luckily, GDB's interpreter mechanism already provides the hooks we
need to do this.  So all I do here is move the newline printing code
from tui_getc_1 into a new function, setup a new input_handler hook
for the tui, and call my new newline printing function.

After this I can enable the tui and paste in 'p 1\r' and see the
correct output.

Also the tuiterm.exp library will now see non-corrupted output.

gdb/ChangeLog:

* tui/tui-interp.c (tui_command_line_handler): New function.
(tui_interp::resume): Register tui_command_line_handler as the
input_handler.
* tui/tui-io.c (tui_inject_newline_into_command_window): New
function.
(tui_getc_1): Delete handling of '\n' and '\r'.
* tui-io.h (tui_inject_newline_into_command_window): Declare.

gdb/testsuite/ChangeLog:

* gdb.tui/scroll.exp: Tighten expected results.  Remove comment
about bug in GDB, update expected results, and add more tests.

gdb/testsuite: fix implementation of delete line in tuiterm.exp

The implementation of the delete line escape sequence in tuiterm.exp
was wrong.  Delete should take a count and then delete COUNT lines at
the current cursor location, all remaining lines in the scroll region
are moved up to replace the deleted lines, with blank lines being
added at the end of the scroll region.

It's not clear to me what "scroll region" means here (or at least how
that is defined), but for now I'm just treating the whole screen as
the scroll region, which seems to work fine.

In contrast the current broken implementation deletes COUNT lines at
the cursor location moving the next COUNT lines up to fill the gap.
The rest of the screen is then cleared.

gdb/testsuite/ChangeLog:

* gdb.tui/scroll.exp: New file.
* gdb.tui/tui-layout-asm-short-prog.exp: Update expected results.
* lib/tuiterm.exp (Term::_csi_M): Delete count lines, scroll
remaining lines up.
(Term::check_region_contents): New proc.
(Term::check_box_contents): Use check_region_contents.

Automatic date update in version.in

ld: Remove x86 ISA level run-time tests

Remove x86 ISA level run-time tests since with glibc 2.33, they will fail
to run on machines with lesser x86 ISA level:

tmpdir/property-5-pie: CPU ISA level is lower than required

PR ld/27358
* testsuite/ld-i386/i386.exp: Remove property 3/4/5 run-time
tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.

Don't draw register sub windows outside the visible area

If the regs window is not big enough to show all registers, the
registers whose values changed are always drawn, even if they are not
in the currently visible area.

So this marks the invisible register sub windows with y=0, and skips
their rerender call in check_register_values.

gdb/ChangeLog:

2021-02-07  Hannes Domani  <ssbssa@yahoo.de>

* tui/tui-regs.c (tui_data_window::display_registers_from):
Mark invisible register sub windows.
(tui_data_window::check_register_values): Ignore invisible
register sub windows.

Don't fill regs window with a negative number of spaces

Function n_spaces can't handle negative values, and returns an invalid
pointer in this case.

gdb/ChangeLog:

2021-02-07  Hannes Domani  <ssbssa@yahoo.de>

* tui/tui-regs.c (tui_data_item_window::rerender): Don't call
n_spaces with a negative value.

Refresh regs window in display_registers_from

Otherwise the register window is redrawn empty when scrolling or
changing its size with winheight.

gdb/ChangeLog:

2021-02-07  Hannes Domani  <ssbssa@yahoo.de>

* tui/tui-regs.c (tui_data_window::display_registers_from):
Add refresh_window call.

Also compare frame_id_is_next in frapy_richcompare

The last frame in a corrupt stack stores the frame_id of the next frame,
so these two frames currently compare as equal.

So if you have a backtrace where the oldest frame is corrupt, this happens:

(gdb) py
 >f = gdb.selected_frame()
 >while f.older():
 >  f = f.older()
 >print(f == f.newer())
 >end
True

With this change, that same example returns False.

gdb/ChangeLog:

2021-02-07  Hannes Domani  <ssbssa@yahoo.de>

* python/py-frame.c (frapy_richcompare): Compare frame_id_is_next.