Add a plugin for processing static library dependencies.

* libdep_plugin.c: New file: Processes archives that contain a
special library dependencies element.
* Makefile.am: Add build rules for libdep_plugin.
* Makefile.in: Regenerate.
* NEWS: Mention the new plugin.
* ld.texi: Document the new plugin.

Put bfd_section_from_shdr loop detection array in elf_tdata

The static variables used by bfd_section_from_shdr to detect loops
in ELF sections have a problem:  Comparing a BFD pointer doesn't
guarantee that the current bfd is the same as the one previously used
to allocate the sections_being_created array.  For example, doing
   size bad_elf_1 bad_elf_2
with two corrupted ELF files containing section loops will leave the
section_being_created array allocated for the first file and since
bfd_close is called for bad_elf_1 before bfd_elf_2 is opened, it is
possible that the BFD for the second file is allocated in the same
memory as the first file.  If bad_elf_2 has more sections than
bad_elf_1 then we might write beyond the end of the array.

So this patch implements the FIXME Nick put in a comment about
attaching the array to the BFD.

* elf-bfd.h (struct elf_obj_tdata): Add being_created.
* elf.c (bfd_section_from_shdr): Delete static vars for loop
detection.  Use new tdata variable instead.
* elfcode.h (elf_object_p): Allocate being_created.

PR26836, memory leak in parse_args

PR 26836
* lexsup.c (parse_args): Free really_longopts, longopts and
shortopts.

Fix a use of an uninitialised variable in the bfd linker.

PR 27050
* lexsup.c (parse_args): Ensure that the longind local variable is
set.

Solaris 11.4 ld build failure

/usr/include/sys/mman.h:81:0: note: this is the location of the previous definition
 #define SHARED  0x10

PR 27064
* deffilep.y (SHARED_K): Rename from SHARED.  Update uses.

rx-elf FAIL: SHF_GNU_RETAIN sections 27

rx-elf is an odd target with non-standard names for default text, data
and bss sections.  This patch tweaks a new test to make it pass.

* testsuite/gas/elf/section27.s: Reorder .text, .data and .bss
so that output section order does not depend on those sections
being already created.  Use ".section .text" rather than ".text".

sim/mips/cp1.c: Include <stdlib.h> for abort() declaration

sim/mips/ChangeLog:

* cp1.c: Include <stdlib.h>

Re-enable incremental tests that were failing with GCC 9+.

gold/
PR gold/23539
PR gold/24123
* testsuite/Makefile.am (incremental_copy_test): Re-enable for GCC 9+.
(incremental_comdat_test_1): Likewise.
* testsuite/Makefile.in: Regenerate.

Automatic date update in version.in

Fix incremental tests using gcc 9, which adds Gnu properties sections.

During an incremental link, we should simply ignore the Gnu properties
sections. We were not handling them properly -- failing to process the
properties from the base file. While that could be fixed, the property
sections are meant for deployed binaries, and incremental linking is
for development, so keeping the properties sections just adds to the
likelihood of forcing a full link sooner.

gold/
PR gold/23539
* object.cc (Sized_relobj_file::layout_gnu_property_section): Ignore
Gnu properties during incremental links.

Fix incremental linking with rodata merge sections.

When processing the incremental update, incoming .rodata merge sections
do not match the corresponding section in the base file, because the
SHF_MERGE flag had not been masked out of the latter.

gold/
PR gold/24123
* layout.cc (Layout::init_fixed_output_section): Mask out flags that
should be ignored when matching sections.

Update ELF headers and readelf with recent e_machine assignments.

binutils/
* readelf.c (get_machine_name): Update list of e_machine values.

include/
* elf/common.h: Update list of e_machine values.

Constify parse_and_eval_type

I noticed that the argumen to parse_and_eval_type could be "const".
This patch implements this change.

I wonder if this could be removed.  It's only called via
check_stub_method_group, which seems questionable to me.  However, I
didn't look into doing this.

gdb/ChangeLog
2020-12-13  Tom Tromey  <tom@tromey.com>

* gdbtypes.c (safe_parse_type): Make argument const.
* value.h (parse_and_eval_type): Make argument const.
* eval.c (parse_and_eval_type): Make argument const.

[gdb/testsuite] Fix gdb.base/endianity.exp with gcc-4.8

When running test-case gdb.base/endianity.exp using gcc-4.8, we get:
...
(gdb) x/x &o.v^M
0x7fffffffd120: 0x00000004^M
(gdb) XFAIL: gdb.base/endianity.exp: x/x &o.v
x/xh &o.w^M
0x7fffffffd124: 0x0003^M
(gdb) FAIL: gdb.base/endianity.exp: x/xh &o.w
...

The gcc 4.8 compiler does not support the scalar_storage_order attribute, so
the testcase is compiled without that attribute, and the expected results are
different.

Fix this by rather than xfailing, skipping the tests if the compiler does not
support the scalar_storage_order attribute.

Tested on x86_64-linux, with gcc-4.8, gcc-7, and clang-10.

gdb/testsuite/ChangeLog:

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

PR testsuite/26953
* gdb.base/endianity.exp: Skip tests requiring scalar_storage_order
attribute support if compiler doesn't support it.

[gdb/testsuite] Handle ada in gdb_compile_shlib

The single test-case in the testsuite that creates an ada shared library is
gdb.ada/catch_ex_std.exp.

The test-case does use gdb_compile_shlib, but with a few tweaks that make sure
things are properly handled for ada.

Move the ada-specific code to gdb_compile_shlib, such that gdb_compile_sh can
be used for ada shared libs without tweaks.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (gdb_compile_shlib): Handle ada.
* gdb.ada/catch_ex_std.exp: Use gdb_compile_shlib to compile from
source to shared lib.  Add ada to options.

[gdb/testsuite] Avoid gnatbind/gnatlink in gdb.ada/catch_ex_std.exp

There's a single test-case in the testsuite that explicitly calls gnatbind and
gnatlink: gdb.ada/catch_ex_std.exp.

Instead, use gnatmake and pass specific gnatbind and gnatlink options using
gnatmake passthrough options -bargs and -largs.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.ada/catch_ex_std.exp: Use gnatmake -bargs and -largs instead of
calling gnatbind and gnatlink.

gdb: new command 'maint flush dcache'

Add a new command to flush the dcache.

gdb/ChangeLog:

* NEWS: Mention new commands.
* target-dcache.c: Add 'cli/cli-cmds.h' include.
(maint_flush_dcache_command): New function.
(_initialize_target_dcache): Create new 'maint flush dcache'
command.

gdb/doc/ChangeLog:

* gdb.texinfo (Caching Target Data): Document 'maint flush
dcache'.

gdb/testsuite/ChangeLog:

* gdb.base/dcache-flush.c: New file.
* gdb.base/dcache-flush.exp: New file.

gdb: introduce new 'maint flush ' prefix command

We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'.  I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.

And so I created the 'maint flush ' command prefix.  Currently there
are two commands:

  (gdb) maint flush symbol-cache
  (gdb) maint flush register-cache

Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild.  So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.

I've updated the testsuite to use the new command syntax, and updated
the documentation too.

gdb/ChangeLog:

* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.

gdb/doc/ChangeLog:

* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.

gdb/testsuite/ChangeLog:

* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.

x86: Do not dump DS/CS segment overrides for branch hints

I've made all labels normal labels so that there's no confusion between
the different targets which is which and I match them in the .d files
with .* as Alan suggested.

Hex offsets I match with [0-9a-fx]+ since some targets prefix them with
0x, some don't, etc.

* testsuite/gas/i386/align-branch-9.s: Don't use labels that are
automatically local for ELF targets.
* testsuite/gas/i386/branch.s: Likewise.
* testsuite/gas/i386/x86-64-align-branch-9.s: Likewise.
* testsuite/gas/i386/x86-64-branch.s: Likewise.
* testsuite/gas/i386/align-branch-9.d: Adjust to match more targets.
* testsuite/gas/i386/branch.d: Likewise.
* testsuite/gas/i386/ilp32/x86-64-branch.d: Likewise.
* testsuite/gas/i386/x86-64-align-branch-9.d: Likewise.
* testsuite/gas/i386/x86-64-branch.d: Likewise.

Automatic date update in version.in

Automatic date update in version.in

gdb: improve the warning given for deprecated aliases with a prefix

Consider this GDB session:

  (gdb) define set xxx_yyy
  Type commands for definition of "set xxx_yyy".
  End with a line saying just "end".
  >echo in set xxx_yyy command\n
  >end
  (gdb) alias set qqq_aaa=set xxx_yyy
  (gdb) maintenance deprecate set qqq_aaa
  (gdb) set qqq_aaa
  Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
  No alternative known.

  in set xxx_yyy command
  (gdb)

Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong.  I think the proper warning should read:

  (gdb) set qqq_aaa
  Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy', is deprecated.
  No alternative known.

With the 'set' prefixes added and a comma before the final 'is
deprecated'.  That is what this patch does.  The expected results are
updated as needed.

gdb/ChangeLog:

* cli/cli-decode.c (deprecated_cmd_warning): Ignore the prefix
result from lookup_cmd_composition_1, use the prefixes from both
the command and the alias instead.
(lookup_cmd_composition_1): Initial prefix command is the based on
the search list being passed in.  Simplify the logic for tracking
the prefix command.  Replace a use of alloca with a local
std::string.

gdb/testsuite/ChangeLog:

* gdb.base/commands.exp: Update expected results.

gdb: make deprecated_cmd_warning i18n friendly

Rewrite deprecated_cmd_warning to be i18n friendly.  While I'm going
through the function I also cleaned up some whitespace issues,
replaced uses of NULL with nullptr, and moved some comments to avoid
having to add { ... }.

Though the message being printed has a 'Warning: ' prefix I could have
changed from using printf_filtered to use warning, however, I haven't
done that in this commit as that would change what GDB outputs and I
wanted this commit NOT to change the output.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* cli/cli-decode.c (deprecated_cmd_warning): Use nullptr instead
of NULL.  Don't print message piece by piece, but sentence at a
time to allow internationalisation.  Some whitespace cleanup.

gdb: give deprecated command warning for aliases with a prefix

I noticed that deprecated aliases that have a prefix don't give a
deprecated command warning.  For example looking in mi/mi-main.c we
see this:

  c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &setlist);
  deprecate_cmd (c, "set mi-async");
  c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &showlist);
  deprecate_cmd (c, "show mi-async");

So both 'set target-async' and 'show target-async' are deprecated and
should be giving a warning, however, in use we see no warning given.

This is a consequence of how the code that should give this
warning (deprecated_cmd_warning) performs a second command lookup in
order to distinguish between aliases and real commands, and that the
code that calls this (lookup_cmd_1) strips off prefix commands as it
calls itself recursively.

As a result when we are considering an alias like 'set target-async'
we first enter lookup_cmd_1 with text = "set target-async", we spot
the 'set' command prefix and then recursively call lookup_cmd_1 with
text = "target-async".

We spot that 'target-async' is a known alias but that it is
deprecated, and so call deprecated_cmd_warning passing in the value of
text, which remember is now "target-async".

In deprecated_cmd_warning we again perform a command lookup starting
from the top-level cmdlist, but now we're trying to find just
"target-async", this fails (as this command requires the 'set' prefix,
and so no warning is given.

I resolved this issue by passing a command list to the function
deprecated_cmd_warning, this is the list in which the command can be
found.

A new test is added to cover this case.

However, there is an additional problem which will be addressed in a
subsequent patch.

Consider this GDB session:

  (gdb) define set xxx_yyy
  Type commands for definition of "set xxx_yyy".
  End with a line saying just "end".
  >echo in set xxx_yyy command\n
  >end
  (gdb) alias set qqq_aaa=set xxx_yyy
  (gdb) maintenance deprecate set qqq_aaa
  (gdb) set qqq_aaa
  Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
  No alternative known.

  in set xxx_yyy command
  (gdb)

Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong.  I think the proper warning should read:

  (gdb) set qqq_aaa
  Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy' is deprecated.
  No alternative known.

With the 'set' prefixes added.  A later patch will resolve this
issue.

gdb/ChangeLog:

PR cli/15104
* cli/cli-decode.c (lookup_cmd_1): Pass command list to
deprecated_cmd_warning.
(deprecated_cmd_warning): Take extra parameter, call
lookup_cmd_composition_1 and pass new parameter through.
(lookup_cmd_composition_1): New function, takes implementation of
lookup_cmd_composition but with extra parameter.
(lookup_cmd_composition): Now calls lookup_cmd_composition_1
passing in cmdlist.
* command.h (deprecated_cmd_warning): Add extra parameter to
declaration.
* top.c (execute_command): Pass cmdlist to deprecated_cmd_warning.

gdb/testsuite/ChangeLog:

PR cli/15104
* gdb.base/commands.exp: Add additional tests.
* gdb.base/completion.exp: Add additional tests.

gdb: don't warn about deprecated aliases during tab completion

Consider this gdb session, where on line #3 tab completion is used:

  (gdb) alias xxx_yyy_zzz=break
  (gdb) maint deprecate xxx_yyy_zzz
  (gdb) xxx_yyy_<TAB>

The third line then updates to look like this:

  (gdb) xxx_yyy_Warning: 'xxx_yyy_zzz', an alias for the command 'break' is deprecated.
  No alternative known.

  zzz

What's happened is during tab completion the alias has been resolved
to the actual command being aliased, and at this stage the warning is
issued.  Clearly this is not what we want during tab completion.

In this commit I add a new parameter to the lookup function, a boolean
that indicates if the lookup is being done as part of completion.
This flag is used to suppress the warning.  Now we get the expected
behaviour, the alias completes without any warning, but the warning is
still given once the user executes the alias.

gdb/ChangeLog:

* cli/cli-decode.c (lookup_cmd_1): Move header comment into
command.h, add extra parameter, and use this to guard giving a
warning.
* command.h (lookup_cmd_1): Add comment from cli/cli-decode.c,
include argument names in declaration, add new argument.
* completer.c (complete_line_internal_1): Remove unneeded
brackets, pass extra argument to lookup_cmd_1.

gdb/testsuite/ChangeLog:

* gdb.base/completion.exp: Add additional tests.

gdbsupport: make use of safe-ctype functions from libiberty

Make use of the safe-ctype replacements for the standard ctype
character checking functions in gdbsupport/common-utils.cc.  The
gdbsupport library is included into both gdb and gdbserver, and on the
gdbserver side there are two targets, gdbserver itself, and also
libinproctrace.so.

libiberty was already being included in the gdbserver link command,
but was missing from the libinproctrace.so link.  As a result, after
changing gdbsupport/common-utils.cc to depend on libiberty,
libinproctrace.so would no longer link until I modified its link line.

gdbserver/ChangeLog:

* Makefile.in (IPA_LIB): Include libiberty library.

gdbsupport/ChangeLog:

* gdbsupport/common-utils.cc: Change 'ctype.h' include to
'safe-ctype.h'.
(extract_string_maybe_quoted): Use safe-ctype function versions.
(is_digit_in_base): Likewise.
(digit_to_int): Likewise.
(strtoulst): Likewise.
(skip_spaces): Likewise.
(skip_to_space): Likewise.

gdb: make debug_infrun a bool

gdb/ChangeLog:

* infrun.h (debug_infrun): Make a bool.
* infrun.c (debug_infrun): Make a bool.
(_initialize_infrun): Use add_setshow_boolean_cmd to define "set
debug infrun".

Change-Id: If934106a6d3f879b93d265855eb705b1d606339a

gdb: factor out debug_prefixed_printf_cond

The same pattern happens often to define a "debug_printf" macro:

    #define displaced_debug_printf(fmt, ...) \
      do \
        { \
          if (debug_displaced) \
     debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \
        } \
      while (0)

Move this pattern behind a helper macro, debug_prefixed_printf_cond and
update the existing macros to use it.

gdb/ChangeLog:

* displaced-stepping.h (displaced_debug_printf): Use
debug_prefixed_printf_cond.
* dwarf2/read.c (dwarf_read_debug_printf): Likewise.
(dwarf_read_debug_printf_v): Likewise.
* infrun.h (infrun_debug_printf): Likewise.
* linux-nat.c (linux_nat_debug_printf): Likewise.

gdbsupport/ChangeLog:

* common-debug.h (debug_prefixed_printf_cond): New.
* event-loop.h (event_loop_debug_printf): Use
debug_prefixed_printf_cond.

Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99

[gdb/testsuite] Update gdb.arch/i386-mpx-call.exp for -m32

When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
we run into:
...
(gdb) continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...

Let's look first for reference at -m64, where the test passes.

The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks in
the exec.  Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
call passes pointer bounds as well as arguments.  The call to upper (with
four pointer arguments and an int argument, passed in 5 registers) is modified
like this:
...
   lea    -0xa0(%rbp),%rcx
   lea    -0x80(%rbp),%rdx
   lea    -0x60(%rbp),%rsi
   lea    -0x40(%rbp),%rax
   mov    $0x0,%r8d
+  bndmov -0x110(%rbp),%bnd3
+  bndmov -0x100(%rbp),%bnd2
+  bndmov -0xf0(%rbp),%bnd1
+  bndmov -0xe0(%rbp),%bnd0
   mov    %rax,%rdi
-  callq  <upper>
+  bnd callq <upper>
...
passsing the four pointer bounds in bounds registers BND0-3.

The top-level mechanism of the test is as follows:
- run the exec to after all mallocs are done, such that all pointer variables
  are valid
- do inferior calls, similar to those present in the program

The inferior call mechanism doesn't differentiate between a call to a function
compiled with -fcheck-pointer-bounds, and one without.  It merely resets the
bound registers to all-allowed state (see amd64_push_dummy_call), to make sure
the checks don't trigger during the inferior call.  [ This is the same as what
happens when executing a call without bnd prefix when the BNDPRESERVE bit of
the BNDCFG register is set to 0, a provision for calling an instrumented
function using a non-instrumented call. ]

First, two inferior calls are done (default_run and verify_default_values)
with the bound registers unmodified by the test.  So, the memory accesses are
performed with the bounds registers set by amd64_push_dummy_call to
all-allowed, and the bounds checks do not trigger.

Then we try to do an inferior call with modified bounds registers, set to
none-allowed.  In order to do that, we set a breakpoint at *upper before
doing the inferior call.  Once we hit the breakpoint during the inferior call,
the bounds registers are set to none-allowed, and we continue expecting to run
into an triggered bounds check, which takes the shape of a sigsegv.

Back to -m32.  Here, the pointer arguments are passed in memory rather than
registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
the Bounds Table using bndstx:
...
  movl   $0x0,0x10(%eax)
  lea    -0x70(%ebp),%edx
  mov    %edx,0xc(%eax)
  lea    -0x5c(%ebp),%edx
  mov    %edx,0x8(%eax)
  lea    -0x48(%ebp),%edx
  mov    %edx,0x4(%eax)
  lea    -0x34(%ebp),%edx
  mov    %edx,(%eax)
  lea    0xc(%eax),%edx
  mov    0xc(%eax),%ecx
  bndmov -0xa8(%ebp),%bnd1
  bndstx %bnd1,(%edx,%ecx,1)
  lea    0x8(%eax),%edx
  mov    0x8(%eax),%ecx
  bndmov -0xa0(%ebp),%bnd3
  bndstx %bnd3,(%edx,%ecx,1)
  lea    0x4(%eax),%edx
  mov    0x4(%eax),%ecx
  bndmov -0x98(%ebp),%bnd1
  bndstx %bnd1,(%edx,%ecx,1)
  mov    (%eax),%edx
  bndmov -0x90(%ebp),%bnd3
  bndstx %bnd3,(%eax,%edx,1)
  bnd call 804893f <upper>
...

Again, the bounds registers are reset at the start of the inferior call by
amd64_push_dummy_call, and modified by the test-case, but neither has any
effect.  The code in upper reads the pointer bounds from the Bounds Table, not
from the bounds registers.

Note that for a test.c with an out-of-bounds access:
...
$ cat test.c
void foo (int *a) { volatile int v = a[1]; }
int main (void) { int a; foo (&a); return 0; }
$ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
$ ./a.out
Saw a #BR! status 1 at 0x804848d
...
and inferior call foo (&a) right before "bnd call foo" (at the point that the
bounds for a are setup in the bounds table) doesn't trigger a bounds violation:
...
(gdb) call foo (&a)
(gdb)
...
This is because the bounds table doesn't associate a pointer with bounds, but
rather a pair of pointer and pointer location.  So, the bound is setup for &a,
with as location the pushed argument in the frame.  The inferior call however
executes in a dummy frame, so the bound is checked for &a with as location the
pushed argument in the dummy frame, which is different, so the bounds check
doesn't trigger.

In conclusion, this is expected behaviour.

Update the test-case to not expect to override effective pointer bounds using
the bounds registers when the bounds passing is done via the Bounds Table.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

PR testsuite/26991
* gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
        violations by setting bounds registers if the bounds are passed in the
        Bounds Table.

Avoid side effects in expression lexers

I noticed that some of the lexers were calling write_dollar_variable
from the lexer.  This seems like a bad practice, so this patch moves
the side effects into the parsers.

I tested this by re-running gdb.fortran and gdb.modula2; the Pascal
compiler on my machine seems not to work, so I couldn't test
gdb.pascal.

I note that the type-tracking in the Pascal is also incorrect, in that
a convenience variable's type may change between parsing and
evaluation (or even during the course of evaluation).

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* p-exp.y (intvar): Remove global.
(DOLLAR_VARIABLE): Change type.
(start): Update.
(exp): Call write_dollar_variable here...
(yylex): ... not here.
* m2-exp.y (DOLLAR_VARIABLE): Change type.
(variable): Call write_dollar_variable here...
(yylex): ... not here.
* f-exp.y (DOLLAR_VARIABLE): Change type.
(exp): Call write_dollar_variable here...
(yylex): ... not here.

Add support for the .bss pseudo-op to the Z80 assembler.

PR 27047
* config/tc-z80.c (s_bss): New function.
(md_pseudo_table): Add bss entry.

install_variable cannot fail

I noticed that install_variable will never return false, so this patch
changes the return type to void.  I couldn't find a spot in history
where it did return false, maybe it's always been like this.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (varobj_create): Update.
(install_variable): Return void.

Use gdbpy_ref in instantiate_pretty_printer

This changes instantiate_pretty_printer to use gdbpy_ref, removing a
call to Py_DECREF.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (instantiate_pretty_printer): Use gdbpy_ref.

Remove varobj_clear_saved_item

One call to varobj_clear_saved_item is from the varobj destructor.
This is no longer needed, so this patch removes the call; then inlines
the function into the sole remaining caller.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (varobj_clear_saved_item): Remove.
(update_dynamic_varobj_children): Update.
(varobj::~varobj): Don't call varobj_clear_saved_item.

Change varobj_item::value to a value_ref_ptr

This changes varobj_item::value to be a value_ref_ptr, removing some
manual management.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (install_dynamic_child, varobj_clear_saved_item)
(update_dynamic_varobj_children, create_child)
(create_child_with_value): Update.
* varobj-iter.h (struct varobj_item) <value>: Now a
value_ref_ptr.
* python/py-varobj.c (py_varobj_iter::next): Call release_value.

Change varobj_dynamic::child_iter to unique_ptr

This changes varobj_dynamic::child_iter to be a unique_ptr, removing
some manual management.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (struct varobj_dynamic) <child_iter>: Now unique_ptr.
(varobj_get_iterator): Return unique_ptr.
(update_dynamic_varobj_children, install_visualizer)
(varobj::~varobj): Update.
* python/python-internal.h (py_varobj_get_iterator): Return
unique_ptr.
* python/py-varobj.c (py_varobj_get_iterator): Return unique_ptr.

Change varobj_dynamic::saved_item to unique_ptr

This changes varobj_dynamic::saved_item to be a unique_ptr.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (struct varobj_dynamic) <saved_item>: Now unique_ptr.
(varobj_clear_saved_item, update_dynamic_varobj_children):
Update.

Change varobj_iter::next to return unique_ptr

This changes varobj_iter::next to return a unique_ptr.  This fits in
with the ongoing theme of trying to express these ownership transfers
via the type system.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (update_dynamic_varobj_children): Update.
* varobj-iter.h (struct varobj_iter) <next>: Change return type.
* python/py-varobj.c (struct py_varobj_iter) <next>: Change return
type.
(py_varobj_iter::next): Likewise.

C++-ify varobj iteration

This changes the varobj iteration code to use a C++ class rather than
a C struct with a separate "ops" structure.  The only implementation
is updated to use inheritance.  This simplifies the code quite nicely.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (update_dynamic_varobj_children, install_visualizer)
(varobj::~varobj): Update.
* varobj-iter.h (struct varobj_iter): Change to interface class.
(struct varobj_iter_ops): Remove.
(varobj_iter_next, varobj_iter_delete): Remove.
* python/py-varobj.c (struct py_varobj_iter): Derive from
varobj_iter.  Add constructor, destructor.  Rename members.
(py_varobj_iter::~py_varobj_iter): Rename from
py_varobj_iter_dtor.
(py_varobj_iter::next): Rename from py_varobj_iter_next.
(py_varobj_iter_ops): Remove.
(py_varobj_iter): Rename from py_varobj_iter_ctor.
(py_varobj_iter_new): Remove.
(py_varobj_get_iterator): Update.

Change all_root_varobjs to take a function_view

This changes all_root_varobjs to take a function_view.  This
simplifies some of the callers, in particular we can remove a data
type that only existed to be passed through.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.h (all_root_varobjs): Take a function_view.
* varobj.c (all_root_varobjs): Take a function_view.
(varobj_invalidate_iter): Remove unused parameter.
(varobj_invalidate): Update.
* mi/mi-cmd-var.c (struct mi_cmd_var_update): Remove.
(mi_cmd_var_update_iter): Change parameters.

Change varobj.c:rootlist to a std::list

This changes varobj.c:rootlist to be a std::list.  This lets us remove
some code.  std::list is chosen because its iterator invalidation
approach suits the all_root_varobjs API.

I considered replacing all_root_varobjs with "external iteration", but
haven't gotten around to doing so.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (struct varobj_root) <next>: Remove.
(struct vlist): Remove.
(rootlist): Now a std::list.
(install_variable, uninstall_variable, all_root_varobjs): Update.

Use htab_t in varobj

varobj.c currently has its own hash table implementation.  This patch
replaces it with htab_t, simplifying the code.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* varobj.c (VAROBJ_TABLE_SIZE): Remove.
(varobj_table): Now htab_t.
(varobj_get_handle, install_variable, uninstall_variable):
Update.
(hash_varobj, eq_varobj_and_string): New functions.
(hash_varobj): Update.

Make bp_location derive from refcounted_object

This changes bp_location to derive from refcounted_object, introduces
a ref_ptr specialization for this type, and then changes
bpstats::bp_location_at to use that specialization.  This removes some
manual reference counting and simplifies the code.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* inline-frame.c (stopped_by_user_bp_inline_frame): Update.
* ada-lang.c (check_status_exception): Update.
* breakpoint.c (free_bp_location): Remove.
(decref_bp_location): Use bp_location_ref_policy.
(bpstats::bpstats): Don't call incref_bp_location.
(bpstats::~bpstats): Remove.
(bpstats::bpstats): Update.
(bpstat_check_watchpoint, bpstat_check_breakpoint_conditions)
(bp_location::bp_location): Update.
(incref_bp_location): Remove.
(bkpt_print_it): Update.
* breakpoint.h (class bp_location): Derive from
refcounted_object.
(struct bpstats): Remove destructor.
<bp_location_at>: Now a bp_location_ref_ptr.
<refc>: Remove.
(bp_location_ref_ptr): New typedef.
(struct bp_location_ref_policy): New.

Remove scoped_inc_dec_ref

We can remove scoped_inc_dec_ref by changing the sole user to instead
keep a vector of thread_info_ref objects.  This removes some manual
reference counting and simplifies the code a bit.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* thread.c (class scoped_inc_dec_ref): Remove.
(tp_array_compar_ascending, tp_array_compar_descending): Change
parameter types.
(thread_apply_all_command): Use thread_info_ref.

Use thread_info_ref in stop_context

This changes stop_context to use a thread_info_ref, removing some
manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* infrun.c (struct stop_context) <thread>: Now a thread_info_ref.
(stop_context::stop_context): Update.
(stop_context::~stop_context): Remove.

Change current_inferior_ to be a inferior_ref

This changes current_inferior_ to be an inferior_ref, removing some
manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* inferior.c (current_inferior_): Change type.
(current_inferior, set_current_inferior, initialize_inferiors):
Update.

Use thread_info_ref in enable_thread_stack_temporaries

This changes enable_thread_stack_temporaries to use a thread_info_ref,
removing some manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

* gdbthread.h (class enable_thread_stack_temporaries) <m_thr>:
Change type.

Handle CPU offset for Ravenscar

The Ravenscar support assumes that the thread ID is the same as the
CPU ID that appears in the Ada task structure.  However, on some
systems, gdbserver will report thread IDs that are off by some
constant.  This can happen, e.g., with qemu in a scenario where there
is an additional (unreported) CPU in the emulation.

The Ada Ravenscar runtimes have been modified to store this offset in
a global variable.  This patch changes gdb to read this variable, when
it exists, and apply the offset to the base CPU ID.  This fixes some
crashes that otherwise occur.

2020-12-11  Tom Tromey  <tromey@adacore.com>

* ada-tasks.c (struct ada_tasks_pspace_data) <cpu_id_offset>: New
field.
(ada_get_tcb_types_info): Look for __gnat_gdb_cpu_first_id.
(read_atcb): Use cpu_id_offset.

Fix a build problem when using FreeBSD 12.

* ar.c (write_archive): Cast iostream pointer to FILE *.
* arsup.c (ar_save): Likewise.
* objcopy.c (copy_file): Likewise.

[gdb/testsuite] Fix gdb.base/float128.exp with --with-mpfr=no

When configuring gdb using --with-mpfr=no and running test-case
gdb.base/float128.exp, we run into:
...
FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!)
...

Fix this by detecting that gdb was build without mpfr using the show
configuration command, and changing the FAIL into UNSUPPORTED.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

PR testsuite/26954
* gdb.base/float128.exp: Detect and handle no mpfr support.

gdb/testsuite: fix race condition in gdb.multi/multi-arch-exec.exp

That test fails intermittently for me.  The problem is a race condition
between the exec syscall and GDB resuming threads.

The initial situation is that we have two threads, let's call them
"leader" and "other".  Leader is the one who is going to do the exec.
We stop at the breakpoint on the all_started function, so both threads
are stopped.  When resuming, GDB resumes leader first and other second.
However, between resuming the two threads, leader has time to run and do
its exec, making other disappear.  When GDB tries to resume other, it is
ino longer there.  We get some "Couldn't get registers: No such
process." messages, and the state is a bit messed up.

The issue can be triggered consistently by adding a small delay after
the resume syscall:

    diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
    index d5a062163c7..9540339a9da 100644
    --- a/gdb/inf-ptrace.c
    +++ b/gdb/inf-ptrace.c
    @@ -308,6 +308,8 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
       gdb_ptrace (request, ptid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal));
       if (errno != 0)
         perror_with_name (("ptrace"));
    +  for (int i = 0 ; i < 100; i++)
    +    usleep (10000);
     }

     /* Wait for the child specified by PTID to do something.  Return the

This patch is about fixing the test to avoid this, since the test is not
about testing this particular corner case.  Handling of multi-threaded
program doing execs should be improved too, but that's not the goal of
this patch.

Fix it by adding a synchronization point in the test to make sure both
threads were resumed by GDB before doing the exec.  I added two
pthread_barrier_wait calls in each thread (for a total of three).  I
think adding one call in each thread would not be enough, because this
could happen:

- both threads reach the first barrier
- the "other" thread is scheduled so has time to run and hit the second
  barrier
- the "leader" thread hits the all_started function breakpoint, causing
  both threads to be stopped by GDB
- GDB resumes the "leader" thread
- Since the "other" thread has already reached the second barrier, the
  "leader" thread is free to run past its second barrier and do the
  exec, while GDB still hasn't resumed the second one

By adding two barrier calls in each thread, I think we are good.  The test
passes consistently for me, even with the artificial delay added.

gdb/testsuite/ChangeLog:

PR gdb/24694
* gdb.multi/multi-arch-exec.c (thread_start, main): Add barrier
calls.

Change-Id: I25c8ea9724010b6bf20b42691c716235537d0e27

Automatic date update in version.in

[gdb/testsuite] Fix gdb.tui/new-layout.exp with tcl 8.5

In commit 4d91ddd342 "[gdb/testsuite] Fix unbalanced braces in
gdb.tui/new-layout.exp", I tried to fix a problem with test-case
gdb.tui/new-layout.exp when running with tcl 8.5.

However, at that point I only had access to the log containing the failure,
and unfortunately my patch turned out not to be effective.

So, finally fix this problem by guarding the problematic code with:
...
if { [tcl_version_at_least 8 6] } { ... }
...

Tested on x86_64-linux, specifically SLE-11 where I ran into the failure.

gdb/testsuite/ChangeLog:

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

PR testsuite/26947
* gdb.tui/new-layout.exp: Don't execute tests with unbalanced curly
braces for tcl 8.5 and earlier.

Fix off-by-one error in ada_fold_name

I'm seeing a libstdc++ assertion failure when running GDB's "maint selftest"
command when GDB is configured with the following CFLAGS and CXXFLAGS as
part of the configure line:

  CFLAGS='-D_GLIBCXX_DEBUG -g3 -O0' CXXFLAGS='-D_GLIBCXX_DEBUG -g3 -O0'

This is what I see when running the self tests:

(gdb) maint selftest
Running selftest aarch64-analyze-prologue.
Running selftest aarch64-process-record.
Running selftest arm-record.
Running selftest arm_analyze_prologue.
Running selftest array_view.
Running selftest child_path.
Running selftest cli_utils.
Running selftest command_structure_invariants.
Running selftest copy_bitwise.
Running selftest copy_integer_to_size.
Running selftest cp_remove_params.
Running selftest cp_symbol_name_matches.
Running selftest dw2_expand_symtabs_matching.
/usr/include/c++/11/string_view:211: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
Aborted (core dumped)

Here's a partial stack trace:

  #0  0x00007ffff6ef6262 in raise () from /lib64/libc.so.6
  #1  0x00007ffff6edf8a4 in abort () from /lib64/libc.so.6
  #2  0x00000000004249bf in std::__replacement_assert (
      __file=0xef7480 "/usr/include/c++/11/string_view", __line=211,
      __function=0xef7328 "constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::ba"...,
      __condition=0xef7311 "__pos < this->_M_len")
      at /usr/include/c++/11/x86_64-redhat-linux/bits/c++config.h:2624
  #3  0x0000000000451737 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffc200, __pos=8)
      at /usr/include/c++/11/string_view:211
  #4  0x00000000004329f5 in ada_fold_name (name="function")
      at /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/ada-lang.c:988

And, looking at frame #4...

(top-gdb) up 4
    at /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/ada-lang.c:988
988 fold_buffer[i] = tolower (name[i]);
(top-gdb) p i
$1 = 8
(top-gdb) p name.size()
$2 = 8

My patch adjusts the comparison to only copy name.size() characters
from the string.  I've added a separate statement for NUL character
termination of fold_buffer[].

gdb/ChangeLog:

* ada-lang.c (ada_fold_name): Fix off-by-one error.

Remove spurious newline on debug printf

I noticed a spurious newline on infrun debugging output. The following patch
fixes that. I'll push as obvious.

gdb/ChangeLog:

2020-12-10  Luis Machado  <luis.machado@linaro.org>

* breakpoint.c (should_be_inserted): Don't output newline.

[AArch64] SVE/FPSIMD fixup for big endian

The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context
structure follows the target endianness, whereas the SVE dumps are
endianness-independent (LE).

Therefore, when the system is in BE mode, we need to reverse the bytes
for the FPSIMD data.

Given the V registers are larger than 64-bit, I've added a way for value
bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits
nicely with the unwinding *_got_bytes function and makes the trad-frame
more flexible and capable of saving larger registers.

The memory for the bytes is allocated via the frame obstack, so it gets freed
after we're done inspecting the frame.

gdb/ChangeLog:

2020-12-10  Luis Machado  <luis.machado@linaro.org>

* aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function.
(aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg.
* aarch64-tdep.h (V_REGISTER_SIZE): Move to ...
* arch/aarch64.h: ... here.
* nat/aarch64-sve-linux-ptrace.c: Include endian.h.
(aarch64_maybe_swab128): New function.
(aarch64_sve_regs_copy_to_reg_buf)
(aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries.
* trad-frame.c (trad_frame_reset_saved_regs): Initialize
the data field.
(TF_REG_VALUE_BYTES): New enum value.
(trad_frame_value_bytes_p): New function.
(trad_frame_set_value_bytes): New function.
(trad_frame_set_reg_value_bytes): New function.
(trad_frame_get_prev_register): Handle register values saved as bytes.
* trad-frame.h (trad_frame_set_reg_value_bytes): New prototype.
(struct trad_frame_saved_reg) <data>: New field.
(trad_frame_set_value_bytes): New prototype.
(trad_frame_value_bytes_p): New prototype.

gdb: move bfd_open_from_target_memory to gdb_bfd

This function allows to create a BFD handle using an accessible memory
range in a target memory.  It is currently contained in a JIT module but
this functionality may be of wider usefullness - for example, reading
ELF binaries contained within a core dump.

gdb/ChangeLog:
2020-12-07  Mihails Strasuns  <mihails.strasuns@intel.com>

* jit.c (mem_bfd*, bfd_open_from_target_memory): Removed.
* gdb_bfd.h (gdb_bfd_open_from_target_memory): New function.
* gdb_bfd.c (mem_bfd*, gdb_bfd_open_from_target_memory): New functions.

RISC-V: Add sext.[bh] and zext.[bhw] pseudo instructions.

https://github.com/riscv/riscv-asm-manual/pull/61

We aleady have sext.w, so just add sext.b, sext.h, zext.b, zext.h
and zext.w.  In a certain sense, zext.b is not a pseudo - It is an
alias of andi.  Similarly, sext.b and sext.h are aliases of other
rvb instructions, when we enable b extension; But they are pseudos
when we just enable rvi.  However, this patch does not consider the
rvb cases.  Besides, zext.w is only valid in rv64.

gas/
    * config/tc-riscv.c (riscv_ext): New function.  Use md_assemblef
    to expand the zext and sext pseudos, to give them a chance to be
    expanded into c-ext instructions.
    (macro): Handle M_ZEXTH, M_ZEXTW, M_SEXTB and M_SEXTH.
    * testsuite/gas/riscv/ext.s: New testcase.
    * testsuite/gas/riscv/ext-32.d: Likewise.
    * testsuite/gas/riscv/ext-64.d: Likewise.
include/
    * opcode/riscv.h (M_ZEXTH, M_ZEXTW, M_SEXTB, M_SEXTH.): Added.
opcodes/
    * riscv-opc.c (riscv_opcodes): Add sext.[bh] and zext.[bhw].

RISC-V: Dump CSR according to the elf privileged spec attributes.

opcodes/
    * disassemble.h (riscv_get_disassembler): Declare.
    * disassemble.c (disassembler): Changed to riscv_get_disassembler.
    * riscv-dis.c (riscv_get_disassembler): Check the elf privileged spec
    attributes before calling print_insn_riscv.
    (parse_riscv_dis_option): Same as the assembler, the priority of elf
    attributes are higher than the options.  If we find the privileged
    attributes, but the -Mpriv-spec= is different, then output error/warning
    and still use the elf attributes set.

RISC-V: Control fence.i and csr instructions by zifencei and zicsr.

bfd/
    * elfxx-riscv.c (riscv_ext_dont_care_version): New function.  Return
    TRUE if we don't care the versions of the extensions.  These extensions
    are added to the subset list for special purposes, with the explicit
    versions or the RISCV_UNKNOWN_VERSION versions.
    (riscv_parse_add_subset): If we do care the versions of the extension,
    and the versions are unknown, then report errors for the non-implicit
    extensions, and return directly for the implicit one.
    (riscv_arch_str1): Do not output i extension after e, and the extensions
    which versions are unknown.
gas/
    * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZICSR
    and INSN_CLASS_ZIFENCEI.
    * testsuite/gas/riscv/march-imply-i.s: New testcase.
    * testsuite/gas/riscv/march-imply-i2p0-01.d: New testcase.  The version
    of i is less than 2.1, and zi* are supported in the chosen spec, so
    enable the fence.i and csr instructions, also output the implicit zi* to
    the arch string.
    * testsuite/gas/riscv/march-imply-i2p0-02.d: Likewise, but the zi* are
    not supported in the spec 2.2.  Enable the related instructions since
    i's version is less than 2.1, but do not output them.
    * testsuite/gas/riscv/march-imply-i2p1-01.d: New testcase.  The version
    of i is 2.1, so don't add it's implicit zi*, and disable the related
    instructions.
    * testsuite/gas/riscv/march-imply-i2p1-01.l: Likewise.
    * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise, and set the zi*
    explicitly, so enable the related instructions.
    * testsuite/gas/riscv/march-imply-i2p0.d: Removed.
    * testsuite/gas/riscv/march-imply-i2p1.d: Removed.
include/
    * opcode/riscv.h: Add INSN_CLASS_ZICSR and INSN_CLASS_ZIFENCEI.
opcodes/
    * riscv-opc.c (riscv_opcodes): Control fence.i and csr instructions by
    zifencei and zicsr.

Automatic date update in version.in

Use add_angle_brackets in ada_lookup_encoded_symbol

Joel recently pointed out add_angle_brackets to me.  This patch
changes one spot in ada-lang.c to use this function rather than doing
it on its own.

gdb/ChangeLog
2020-12-09  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_lookup_encoded_symbol): Use add_angle_brackets.

Handle 128-bit constants for fixed point

In some cases, GNAT can emit 128-bit constants for fixed-point types.
This patch changes gdb to handle this scenario, by changing the
low-level rational-reading functions in dwarf2/read.c to work directly
with gdb_mpz values.  (I'm not sure offhand if these 128-bit patches
have gone into upstream GCC yet -- but they will eventually, and
meanwhile I think it should be clear that this patch is otherwise
harmless.)

gdb/ChangeLog
2020-12-09  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (get_dwarf2_rational_constant): Change "numerator"
and "denominator" to gdb_mpz.  Handle block forms.
(get_dwarf2_unsigned_rational_constant): Change "numerator" and
"denominator" to gdb_mpz.
(finish_fixed_point_type): Update.
(has_zero_over_zero_small_attribute): Update.

Unify all operators into std-operator.def

This removes ada-operator.def and fortran-operator.def, merging their
contents into std-operator.def.

Note that the comment for OP_EXTENDED0 is a bit wrong.  IMO this
constant could be removed, as it is only used for a single assert that
does not provide much value.  However, I haven't done so here.

gdb/ChangeLog
2020-12-09  Tom Tromey  <tromey@adacore.com>

* expprint.c (op_name): Update.
* expression.h (enum exp_opcode): Update.
* std-operator.def: Add more opcodes.
* ada-operator.def, fortran-operator.def: Remove, moving contents
into std-operator.def.

gdb: address review comments of previous series

I forgot to include fixes for review comments I got before pushing the
previous commits (or I pushed the wrong commits).  This one fixes it.

 - Return {} instead of false in get_discrete_low_bound and
   get_discrete_high_bound.
 - Compute high bound after confirming low bound is valid in
   get_discrete_bounds.

gdb/ChangeLog:

* gdbtypes.c (get_discrete_low_bound, get_discrete_high_bound):
Return {} instead of false.
(get_discrete_bounds): Compute high bound only if low bound is
valid.

Change-Id: I5f9a66b3672adfac9441068c899ab113ab2c331a

gdb: fix value_subscript when array upper bound is not known

Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for
non-constant range bounds"), subscripting  flexible array member fails:

    struct no_size
    {
      int n;
      int items[];
    };

    (gdb) p *ns
    $1 = {n = 3, items = 0x5555555592a4}
    (gdb) p ns->items[0]
    Cannot access memory at address 0xfffe555b733a0164
    (gdb) p *((int *) 0x5555555592a4)
    $2 = 101  <--- we would expect that
    (gdb) p &ns->items[0]
    $3 = (int *) 0xfffe5559ee829a24  <--- wrong address

Since the flexible array member (items) has an unspecified size, the array type
created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0,
Ubuntu 20.04):

    0x000000a4:   DW_TAG_array_type
                    DW_AT_type [DW_FORM_ref4]       (0x00000038 "int")
                    DW_AT_sibling [DW_FORM_ref4]    (0x000000b3)

    0x000000ad:     DW_TAG_subrange_type
                      DW_AT_type [DW_FORM_ref4]     (0x00000031 "long unsigned int")

This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined
constant low bound (dynamic_prop with kind PROP_CONST) and an undefined
high bound (dynamic_prop with kind PROP_UNDEFINED).

value_subscript gets both bounds of that range using
get_discrete_bounds.  Before commit 7c6f27129631, get_discrete_bounds
didn't check the kind of the dynamic_props and would just blindly read
them as if they were PROP_CONST.  It would return 0 for the high bound,
because we zero-initialize the range_bounds structure.  And it didn't
really matter in this case, because the returned high bound wasn't used
in the end.

Commit 7c6f27129631 changed get_discrete_bounds to return a failure if
either the low or high bound is not a constant, to make sure we don't
read a dynamic prop that isn't a PROP_CONST as a PROP_CONST.  This
change made get_discrete_bounds start to return a failure for that
range, and as a result would not set *lowp and *highp.  And since
value_subscript doesn't check get_discrete_bounds' return value, it just
carries on an uses an uninitialized value for the low bound.  If
value_subscript did check the return value of get_discrete_bounds, we
would get an error message instead of a bogus value.  But it would still
be a bug, as we wouldn't be able to print the flexible array member's
elements.

Looking at value_subscript, we see that the low bound is always needed,
but the high bound is only needed if !c_style.  So, change
value_subscript to use get_discrete_low_bound and
get_discrete_high_bound separately.  This fixes the case described
above, where the low bound is known but the high bound isn't (and is not
needed).  This restores the original behavior without accessing a
dynamic_prop in a wrong way.

A test is added.  In addition to the case described above, a case with
an array member of size 0 is added, which is a GNU C extension that
existed before flexible array members were introduced.  That case
currently fails when compiled with gcc <= 8.  gcc <= 8 produces DWARF
similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in
there, which makes the high bound known.  A case where an array member
of size 0 is the only member of the struct is also added, as that was
how PR 28675 was originally reported, and it's an interesting corner
case that I think could trigger other funny bugs.

Question about the implementation: in value_subscript, I made it such
that if the low or high bound is unknown, we fall back to zero.  That
effectively makes it the same as it was before 7c6f27129631.  But should
we instead error() out?

gdb/ChangeLog:

PR 26875, PR 26901
* gdbtypes.c (get_discrete_low_bound): Make non-static.
(get_discrete_high_bound): Make non-static.
* gdbtypes.h (get_discrete_low_bound): New declaration.
(get_discrete_high_bound): New declaration.
* valarith.c (value_subscript): Only fetch high bound if
necessary.

gdb/testsuite/ChangeLog:

PR 26875, PR 26901
* gdb.base/flexible-array-member.c: New test.
* gdb.base/flexible-array-member.exp: New test.

Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7

gdb: split get_discrete_bounds in two

get_discrete_bounds is not flexible for ranges (TYPE_CODE_RANGE), in the
sense that it returns true (success) only if both bounds are present and
constant values.

This is a problem for code that only needs to know the low bound and
fails unnecessarily if the high bound is unknown.

Split the function in two, get_discrete_low_bound and
get_discrete_high_bound, that both return an optional.  Provide a new
implementation of get_discrete_bounds based on the two others, so the
callers don't have to be changed.

gdb/ChangeLog:

* gdbtypes.c (get_discrete_bounds): Implement with
get_discrete_low_bound and get_discrete_high_bound.
(get_discrete_low_bound): New.
(get_discrete_high_bound): New.

Change-Id: I986b5e9c0dd969800e3fb9546af9c827d52e80d0

gdb: make get_discrete_bounds return bool

get_discrete_bounds currently has three possible return values (see its
current doc for details).  It appears that for all callers, it would be
sufficient to have a boolean "worked" / "didn't work" return value.

Change the return type of get_discrete_bounds to bool and adjust all
callers.  Doing so simplifies the following patch.

gdb/ChangeLog:

* gdbtypes.h (get_discrete_bounds): Return bool, adjust all
callers.
* gdbtypes.c (get_discrete_bounds): Return bool.

Change-Id: Ie51feee23c75f0cd7939742604282d745db59172

gdb: make discrete_position return optional

Instead of returning a boolean status and returning the value through a
pointer, return an optional that does both jobs.  This helps in the
following patches, and I think it is an improvement in general.

gdb/ChangeLog:

* ada-lang.c (ada_value_slice_from_ptr): Adjust.
(ada_value_slice): Adjust.
(pos_atr): Adjust.
* gdbtypes.c (get_discrete_bounds): Adjust.
(discrete_position): Return optional.
* gdbtypes.h (discrete_position): Return optional.

Change-Id: I758dbd8858b296ee472ed39ec35db1dbd624a5ae

gas: Generate a new section for SHF_GNU_RETAIN

For
.globl foo2
.section .data.foo,"aR"
.align 4
.type foo2, @object
.size foo2, 4
foo2:
.long 2
.globl foo1
.section .data.foo
.align 4
.type foo1, @object
.size foo1, 4
foo1:
.long 1

generate a new section if the SHF_GNU_RETAIN bit doesn't match.

* config/obj-elf.c (SEC_ASSEMBLER_SHF_MASK): New.
(get_section_by_match): Also check if SEC_ASSEMBLER_SHF_MASK of
sh_flags matches.  Rename info to sh_info.
(obj_elf_change_section): Don't check previous SHF_GNU_RETAIN.
Rename info to sh_info.
(obj_elf_section): Rename info to sh_info.  Set sh_flags for
SHF_GNU_RETAIN.
* config/obj-elf.h (elf_section_match): Rename info to sh_info.
Add sh_flags.
* testsuite/gas/elf/elf.exp: Run section27.
* testsuite/gas/elf/section24b.d: Updated.
* testsuite/gas/elf/section27.d: New file.
* testsuite/gas/elf/section27.s: Likewise.

Automatic date update in version.in

gdbsupport: Use LOCALAPPDATA to determine cache dir

Use the LOCALAPPDATA environment variable to determine the cache dir
when running on Windows with native command line, otherwise nasty
warning "Couldn't determine a path for index cached directory" appears.

Change-Id: I77903f9f0cb4743555866b8aea892cef55132589

[gdb/testsuite] Simplify gdb.arch/amd64-gs_base.exp

Redo fix committed in commit 67748e0f66 "[gdb/testsuite] Make
gdb.arch/amd64-gs_base.exp unsupported for i386" using is_amd64_regs_target.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.arch/amd64-gs_base.exp: Undo commit 67748e0f66, reimplement
using is_amd64_regs_target.

[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp for -m32

When running test-case gdb.ada/mi_task_arg.exp with target board unix/-m32, I
run into:
...
(gdb) ^M
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[ \
  frame={level="0",args=\[\]}, \
  frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}\]}, \
  frame={level="2",args=\[({name="self_id",value="0x[0-9A-Fa-f]+"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[ \
  frame={level="0",args=[]}, \
  frame={level="1",args=[{name="<_task>",value="0x808abf0"}]}, \
  frame={level="2",args=[{name="self_id",value="<optimized out>"}]}, \
  frame={level="3",args=[]},frame={level="4",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...

The problem is that we're expecting a $hex for the value of self_id, but
instead get <optimized out>.

Looking at the debug info for self_id:
...
 <1><12a1f>: Abbrev Number: 84 (DW_TAG_subprogram)
    <12a20>   DW_AT_name        : system__tasking__stages__task_wrapper
    ...
 <2><12a35>: Abbrev Number: 61 (DW_TAG_formal_parameter)
    <12a36>   DW_AT_name        : self_id
    <12a40>   DW_AT_location    : 0x459e (location list)
...
it refers to location information here:
...
    0000459e 08053060 080531ac (DW_OP_fbreg: 0)
    000045aa 0805327c 080532a5 (DW_OP_fbreg: 0)
    000045b6 08053320 08053324 (DW_OP_fbreg: 0)
...
while the pc used to retrieve the location information is 0x080531c5:
...
 $ gdb -batch outputs/gdb.ada/mi_task_arg/task_switch \
   -ex "break 57" -ex run -ex bt
   ...
 #0  task_switch.break_me () at task_switch.adb:57
 #1  0x0804aaae in task_switch.caller (<_task>=0x808abf0) \
                     at task_switch.adb:51
 #2  0x080531c5 in system.tasking.stages.task_wrapper \
                     (self_id=<optimized out>) at s-tassta.adb:1295
...
which indeed falls outside of the ranges listed in the location info.

Fix this by accepting <optimized out> as valid value of self_id.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.ada/mi_task_arg.exp: Accept <optimized out> as valid value of
self_id.

Automatic date update in version.in

gdb.base/break-on-linker-gcd-function.exp: Remove unused variable

Commit:

 commit 4d142eaa28c64565b58fcdb5a83377ec9b778cb1
 Author:     Jan Kratochvil <jan.kratochvil@redhat.com>
 AuthorDate: Tue Jul 2 20:06:12 2013 +0000

     gdb/testsuite/
     * gdb.base/break-on-linker-gcd-function.exp: Replace
     prepare_for_testing by build_executable_from_specs and clean_restart.
 ...

did:

 set additional_flags {-ffunction-sections -Wl,--gc-sections}
 -if {[prepare_for_testing $testfile.exp $testfile $srcfile \
 -        [list debug c++ additional_flags=$additional_flags]]} {
 +if {[build_executable_from_specs $testfile.exp $testfile \
 +       {c++ additional_flags=-Wl,--gc-sections} \
 +       $srcfile {debug c++ additional_flags=-ffunction-sections}]} {

and that left the additional_flags variable behind.  Remove it.

gdb/testsuite/ChangeLog:

* gdb.base/break-on-linker-gcd-function.exp: Remove unused
'additional_flags' variable.

Remove references to the unofficial SHF_GNU_BUILD_NOTE section flag.

binutils * objcopy.c (is_mergeable_note_section): Remove reference to
SHF_GNU_BUILD_NOTE.

include * elf/common.h (SHF_GNU_BUILD_NOTE): Delete.

binutils: Make smart_rename safe too

smart_rename is capable of handling symlinks by copying and it also
tries to preserve ownership and permissions of files when they're
overwritten during the rename.  This is useful in objcopy where the
file properties need to be preserved.

However because smart_rename does this using file names, it leaves a
race window between renames and permission fixes.  This change removes
this race window by using file descriptors from the original BFDs that
were used to manipulate these files wherever possible.

The file that is to be renamed is also passed as a file descriptor so
that we use fchown/fchmod on the file descriptor, thus making sure
that we only modify the file we have opened to write.  Further, in
case the file is to be overwritten (as is the case in ar or objcopy),
the permissions that need to be restored are taken from the file
descriptor that was opened for input so that integrity of the file
status is maintained all the way through to the rename.

binutils/

* rename.c
* ar.c
(write_archive) [!defined (_WIN32) || defined (__CYGWIN32__)]:
Initialize TARGET_STAT and OFD to pass to SMART_RENAME.
* arsup.c
(ar_save) [defined (_WIN32) || defined (__CYGWIN32__)]:
Likewise.
* bucomm.h (smart_rename): Add new arguments to declaration.
* objcopy.c
(strip_main)[defined (_WIN32) || defined (__CYGWIN32__)]:
Initialize COPYFD and pass to SMART_RENAME.
(copy_main) [defined (_WIN32) || defined (__CYGWIN32__)]:
Likewise.
* rename.c (try_preserve_permissions): New function.
(smart_rename): Use it and add new arguments.

objcopy: Get input file stat after BFD open

Get file state from the descriptor opened by copy_file for the input
BFD.  This ensures continuity in the view of the input file through
the descriptor.  At the moment it is only to preserve timestamps
recorded at the point that we opened the file for input but in the
next patch this state will also be used to preserve ownership and
permissions wherever applicable.

binutils/

* objcopy.c (copy_file): New argument IN_STAT.  Return stat of
ibfd through it.
(strip_main): Remove redundant stat calls.  adjust copy_file
calls.
(copy_main): Likewise.

binutils: Use file descriptors from make_tempname

The purpose of creating a temporary file securely using mkstemp is
defeated if it is closed in make_tempname and reopened later for use;
it is as good as using mktemp.  Get the file descriptor instead and
then use it to create the BFD object.

bfd/

* opncls.c (bfd_fdopenw): New function.
* bfd-in2.h: Regenerate.

binutils/

* bucomm.c (make_tempname): Add argument to return file
descriptor.
* bucomm.h (make_tempname): Likewise.
* ar.c: Include libbfd.h.
(write_archive): Adjust for change in make_tempname.  Call
bfd_fdopenw instead of bfd_openw.
* objcopy.c: Include libbfd.h.
(copy_file): New argument OFD.  Use bfd_fdopenw instead of
bfd_openw.
(strip_main): Adjust for change in make_tempname and
copy_file.
(copy_main): Likewise.

Use expression completer for "maint print type"

I happened to notice that expression completion did not work correctly
for "maint print type".  This patch adds the appropriate completer
there.

gdb/ChangeLog
2020-12-07  Tom Tromey  <tromey@adacore.com>

* maint.c (_initialize_maint_cmds): Use expression command
completer for "maint print type".

[GOLD] gcc-11 stringop-overflow warning

I'm unsure why this is deserving of a warning.  Not writing the most
efficient code surely can't be a real problem, but that is what
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059#c1 seems to say.

plugin.cc:528:10: error: 'char* strncpy(char*, const char*, size_t)' specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
  528 |   strncpy(tempdir, dir_template, len);
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugin.cc:526:22: note: length computed here
  526 |   size_t len = strlen(dir_template) + 1;
      |                ~~~~~~^~~~~~~~~~~~~~

* plugin.cc (Plugin_recorder::init): Replace strncpy with memcpy.

elf32-csky.c:3932:19: error: comparison is always false

It looks like csky missed out on an edit for 706704c8834.  Not that it
matters very much.  There doesn't appear to be any csky reloc howto
that sets the negate bit.

Similarly for ns32k and nds32.

* elf32-csky.c (csky_relocate_contents): Correct negate test.
* cpu-ns32k.c (_bfd_do_ns32k_reloc_contents): Likewise.
* elf32-nds32.c (nds32_relocate_contents): Likewise.

README-how-to-make-a-release (point releases): Add a note to update the milestone list on sourceware's bugzilla.

gdb/completer: improve tab completion to consider the '-force-condition' flag

The commit

  commit 733d554a4625db4ffb89b7a20e1cf27ab071ef4d
  Author: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
  Date:   Tue Oct 27 10:56:03 2020 +0100

  gdb/breakpoint: add flags to 'condition' and 'break' commands to force condition

introduced the '-force-condition' flag to the 'break' command.  This
flag was defined as a keyword like 'thread', 'task', and 'if'.
However, it starts with '-'.  This difference caused an uncovered case
when tab-completing a seemingly complete linespec.

Below, we see "-force-condition" in the completion list, where both
the options and the keywords are listed:

  (gdb) break -function main <TAB>
  -force-condition  -function  -label  -line  -qualified
  -source           if         task    thread

But tab-completing '-' lists only options:

  (gdb) break -function main -<TAB>
  -function   -label      -line       -qualified  -source

This patch fixes the problem by adding keywords to the completion
list, so that we see:

  (gdb) break -function main -<TAB>
  -force-condition  -function  -label  -line  -qualified  -source

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

* completer.c (complete_explicit_location): Also add keywords
that start with '-' to the completion list.

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

* gdb.linespec/explicit.exp: Extend with a test to check completing
'-' after seemingly complete options.

gdb/linespec: relax the position of the '-force-condition' flag

The break command's "-force-condition" flag is currently required to
be followed by the "if" keyword.  This prevents flexibility when using
other keywords, e.g. "thread":

  (gdb) break main -force-condition thread 1 if foo
  Function "main -force-condition" not defined.
  Make breakpoint pending on future shared library load? (y or [n]) n

Remove the requirement that "-force-condition" is always followed by
an "if", so that more flexibility is obtained when positioning
keywords.

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

* linespec.c (linespec_lexer_lex_keyword): The "-force-condition"
keyword may be followed by any keyword.
* breakpoint.c (find_condition_and_thread): Advance 'tok' by
'toklen' in the case for "-force-condition".

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

* gdb.linespec/keywords.exp: Add tests to check positional
flexibility of "-force-condition".

gdb/main: execute breakpoint commands for '-iex' and '-ex' commands

Suppose we have the script file below:

  break main
  commands
    print 123
  end
  run

If started with this script file, GDB executes the breakpoint command:

  $ gdb -q -x myscript --args ./test
  Reading symbols from ./test...
  Breakpoint 1 at 0x114e: file test.c, line 2.

  Breakpoint 1, main () at test.c:2
  2         return 0;
  $1 = 123
  (gdb)

However, if we remove the "run" line from the script and pass it with
the '-ex' option instead, the command is not executed:

  $ gdb -q -x myscript_no_run --args ./test
  Reading symbols from ./test...
  Breakpoint 1 at 0x114e: file test.c, line 2.
  Starting program: /path/to/test

  Breakpoint 1, main () at test.c:2
  2         return 0;
  (gdb)

If the user enters a command at this point, the breakpoint command
is executed, yielding weird output:

  $ gdb -q -x myscript_no_run --args ./test
  Reading symbols from ./test...
  Breakpoint 1 at 0x114e: file test.c, line 2.
  Starting program: /path/to/test

  Breakpoint 1, main () at test.c:2
  2         return 0;
  (gdb) print "a"
  $1 = "a"
  $2 = 123

When consuming script files, GDB runs bp actions after executing a
command.  See `command_handler` in event-top.c:

  if (c[0] != '#')
    {
      execute_command (command, ui->instream == ui->stdin_stream);

      /* Do any commands attached to breakpoint we stopped at.  */
      bpstat_do_actions ();
    }

However, for '-ex' commands, `bpstat_do_actions` is not invoked.
Hence, the misaligned output explained above occurs.  To fix the
problem, add a call to `bpstat_do_actions` after executing a command.

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

* main.c (catch_command_errors): Add a flag parameter; invoke
`bpstat_do_actions` if the flag is set.
(execute_cmdargs): Update a call to `catch_command_errors`.

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

* gdb.base/bp-cmds-run-with-ex.c: New file.
* gdb.base/bp-cmds-run-with-ex.exp: New file.
* gdb.base/bp-cmds-run-with-ex.gdb: New file.
* gdb.gdb/python-interrupts.exp: Update the call to
'catch_command_errors' with the new argument.
* gdb.gdb/python-selftest.exp: Ditto.

[gdb/ada] Handle shrink resize in replace_operator_with_call

In replace_operator_with_call, we resize the elts array like this:
...
  exp->nelts = exp->nelts + 7 - oplen;
  exp->resize (exp->nelts);
...

Although all the current callers ensure that the new size is bigger, it could
also be smaller, in which case the following memmove possibly reads out of
bounds:
...
   memmove (exp->elts + pc + 7, exp->elts + pc + oplen,
           EXP_ELEM_TO_BYTES (save_nelts - pc - oplen));
...

Fix this by doing the resize after the memmove in case the new size is
smaller.

Tested on x86_64-linux.

gdb/ChangeLog:

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

* ada-lang.c (replace_operator_with_call): Handle shrink resize.

Fix struct expression regression

The patch to change struct expression to use new introduced a
regression -- there is a spot that reallocates expressions that I
failed to update.

This patch rewrites this code to follow the new approach.  Now the
rewriting is done in place.

gdb/ChangeLog
2020-12-06  Tom Tromey  <tom@tromey.com>

PR ada/26999
* ada-lang.c (replace_operator_with_call): Rewrite.

Automatic date update in version.in

s390: Fix BC instruction breakpoint handling

This fixes a long-lived bug in the s390 port.

When trying to step over a breakpoint set on a BC (branch on condition)
instruction with displaced stepping on IBM Z, gdb would incorrectly
adjust the pc regardless of whether or not the branch was taken. Since
the branch target is an absolute address, this would cause the inferior
to jump around wildly whenever the branch was taken, either crashing it
or causing it to behave unpredictably.

It turns out that the logic to handle BC instructions correctly was in
the code, but that the enum value representing its opcode has always
been incorrect.

This patch corrects the enum value to the actual opcode, fixing the
stepping problem. The enum value is also used in the prologue analysis
code, so this also fixes a minor bug where more of the prologue would
be read than was necessary.

gdb/ChangeLog:

        PR breakpoints/27009
        * s390-tdep.h (op_bc): Correct BC opcode value.

gmp-utils: protect gdb_mpz exports against out-of-range values

The gdb_mpz class currently provides a couple of methods which
essentially export an mpz_t value into either a buffer, or an integral
type. The export is based on using the mpz_export function which
we discovered can be a bit treacherous if used without caution.

In particular, the initial motivation for this patch was to catch
situations where the mpz_t value was so large that it would not fit
in the destination area. mpz_export does not know the size of
the buffer, and therefore can happily write past the end of our buffer.

While designing a solution to the above problem, I also discovered
that we also needed to be careful when exporting signed numbers.
In particular, numbers which are larger than the maximum value
for a given signed type size, but no so large as to fit in the
*unsigned* version with the same size, would end up being exported
incorrectly. This is related to the fact that mpz_export ignores
the sign of the value being exportd, and assumes an unsigned export.
Thus, for such large values, the appears as if mpz_export is able
to fit our value into our buffer, but in fact, it does not.

Also, I noticed that gdb_mpz::write wasn't taking its unsigned_p
parameter, which was a hole.

For all these reasons, a new low-level private method called
"safe_export" has been added to class gdb_mpz, whose goal is
to perform all necessary checks and manipulations for a safe
and correct export. As a bonus, this method allows us to factorize
the handling of negative value exports.

The gdb_mpz::as_integer and gdb_mpz::write methods are then simplified
to take advantage of this new safe_export method.

gdb/ChangeLog:

        * gmp-utils.h (gdb_mpz::safe_export): New private method.
        (gdb_mpz::as_integer): Reimplement using gdb_mpz::safe_export.
        * gmp-utils.c (gdb_mpz::write): Rewrite using gdb_mpz::safe_export.
        (gdb_mpz::safe_export): New method.
        * unittests/gmp-utils-selftests .c (gdb_mpz_as_integer):
        Update function description.
        (check_as_integer_raises_out_of_range_error): New function.
        (gdb_mpz_as_integer_out_of_range): New function.
        (_initialize_gmp_utils_selftests): Register
        gdb_mpz_as_integer_out_of_range as a selftest.

Automatic date update in version.in

VAX/BFD: Do not warn about GOT addend mismatches if no GOT entry is made

Match the condition used in `elf_vax_instantiate_got_entries' for the
creation of GOT entries in the processing of R_VAX_GOT32 relocations in
`elf_vax_check_relocs', removing incorrect warnings about a GOT addend
mismatch like:

./ld-new: tmpdir/got-local-ref-off-r.o: warning: GOT addend of 1 to `bar_hidden' does not match previous GOT addend of 0
./ld-new: tmpdir/got-local-ref-off-r.o: warning: GOT addend of 2 to `bar_hidden' does not match previous GOT addend of 0

and corresponding failures with the test cases newly added here:

FAIL: GOT test (executable hidden reference with offset)
FAIL: GOT test (executable visible reference with offset)

for symbols that are considered local for reasons other than having been
forced local with a version script, which is usually the ELF visibility.
Correct code is produced regardless, but the warning breaks `-Werror'
compilation and may upset people regardless.

Interestingly this shows with executable links only, because in shared
library links code from `elf_link_add_object_symbols' triggers:

    /* If the symbol already has a dynamic index, but
       visibility says it should not be visible, turn it into
       a local symbol.  */
    switch (ELF_ST_VISIBILITY (h->other))
      {
      case STV_INTERNAL:
      case STV_HIDDEN:
(*bed->elf_backend_hide_symbol) (info, h, TRUE);
dynsym = FALSE;
break;
      }

that sets `h->forced_local' like with a version script.

Add suitable test cases including disassembly to verify correct code has
been produced where no warnings have been issued, and that warnings do
get issued where necessary.  Do not verify (broken) code produced in the
latter case; we should probably make the warning an error, or preferably
actually start supporting GOT references with different addends as they
appear feasible with explicitly relocated GOT that we use.

bfd/
* elf32-vax.c (elf_vax_check_relocs) <R_VAX_GOT32>: Use
SYMBOL_REFERENCES_LOCAL rather than `h->forced_local' to check
whether the symbol referred is local or not.

ld/
* testsuite/ld-vax-elf/got-local-exe-off-hidden.dd: New test
dump.
* testsuite/ld-vax-elf/got-local-exe-off-visible.dd: New test
dump.
* testsuite/ld-vax-elf/got-local-lib-off-hidden.dd: New test
dump.
* testsuite/ld-vax-elf/got-local-lib-off-visible.ed: New test
dump.
* testsuite/ld-vax-elf/got-local-off-external.ed: New test dump.
* testsuite/ld-vax-elf/got-local-exe-off.xd: New test dump.
* testsuite/ld-vax-elf/got-local-lib-off.xd: New test dump.
* testsuite/ld-vax-elf/got-local.ld: New test linker script.
* testsuite/ld-vax-elf/got-local-aux-off.s: New test source.
* testsuite/ld-vax-elf/got-local-def-off.s: New test source.
* testsuite/ld-vax-elf/got-local-ref-off-external.s: New test
source.
* testsuite/ld-vax-elf/got-local-ref-off-hidden.s: New test
source.
* testsuite/ld-vax-elf/got-local-ref-off-visible.s: New test
source.
* testsuite/ld-vax-elf/vax-elf.exp: Run the new tests.

Fix TARGET_CHAR_BIT/HOST_CHAR_BIT confusion in gmp-utils.c

In a couple of gdb_mpz methods, we are computing the number of
bits in a gdb::array_view of gdb_byte. Since gdb_byte is defined
using a host-side type (see common-types.h), the number of bits
in a gdb_byte should be HOST_CHAR_BIT, not TARGET_CHAR_BIT.

gdb/ChangeLog:

        * gmp-utils.c (gdb_mpz::read): Use HOST_CHAR_BIT instead of
        TARGET_CHAR_BIT.
        (gdb_mpz::write): Likewise.

x86-64: Convert load to mov only for GOTPCRELX relocations

Since converting load to mov needs to rewrite the REX byte and we don't
know if there is a REX byte with GOTPCREL relocation, do it only for
GOTPCRELX relocations.

bfd/

PR ld/27016
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Convert load
to mov only for GOTPCRELX relocations.

ld/

PR ld/27016
* testsuite/ld-x86-64/x86-64.exp: Run pr27016a and pr27016b.
* testsuite/ld-x86-64/pr27016a.d: New file.
* testsuite/ld-x86-64/pr27016a.s: Likewise.
* testsuite/ld-x86-64/pr27016b.d: Likewise.
* testsuite/ld-x86-64/pr27016b.s: Likewise.

Automatic date update in version.in

gdb: use two displaced step buffers on amd64/Linux

As observed on a binary compiled on AMD64 Ubuntu 20.04, against glibc
2.31 (I think it's the libc that provides this startup code, right?),
there are enough bytes at the executable's entry point to hold more than
one displaced step buffer.  gdbarch_max_insn_length is 16, and the
code at _start looks like:

0000000000001040 <_start>:
    1040:       f3 0f 1e fa             endbr64
    1044:       31 ed                   xor    %ebp,%ebp
    1046:       49 89 d1                mov    %rdx,%r9
    1049:       5e                      pop    %rsi
    104a:       48 89 e2                mov    %rsp,%rdx
    104d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    1051:       50                      push   %rax
    1052:       54                      push   %rsp
    1053:       4c 8d 05 56 01 00 00    lea    0x156(%rip),%r8        # 11b0 <__libc_csu_fini>
    105a:       48 8d 0d df 00 00 00    lea    0xdf(%rip),%rcx        # 1140 <__libc_csu_init>
    1061:       48 8d 3d c1 00 00 00    lea    0xc1(%rip),%rdi        # 1129 <main>
    1068:       ff 15 72 2f 00 00       callq  *0x2f72(%rip)        # 3fe0 <__libc_start_main@GLIBC_2.2.5>
    106e:       f4                      hlt
    106f:       90                      nop

The two buffers would occupy [0x1040, 0x1060).

I checked on Alpine, which uses the musl C library, the startup code
looks like:

0000000000001048 <_start>:
    1048:       48 31 ed                xor    %rbp,%rbp
    104b:       48 89 e7                mov    %rsp,%rdi
    104e:       48 8d 35 e3 2d 00 00    lea    0x2de3(%rip),%rsi        # 3e38 <_DYNAMIC>
    1055:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    1059:       e8 00 00 00 00          callq  105e <_start_c>

000000000000105e <_start_c>:
    105e:       48 8b 37                mov    (%rdi),%rsi
    1061:       48 8d 57 08             lea    0x8(%rdi),%rdx
    1065:       45 31 c9                xor    %r9d,%r9d
    1068:       4c 8d 05 47 01 00 00    lea    0x147(%rip),%r8        # 11b6 <_fini>
    106f:       48 8d 0d 8a ff ff ff    lea    -0x76(%rip),%rcx        # 1000 <_init>
    1076:       48 8d 3d 0c 01 00 00    lea    0x10c(%rip),%rdi        # 1189 <main>
    107d:       e9 9e ff ff ff          jmpq   1020 <__libc_start_main@plt>

Even though there's a _start_c symbol, it all appears to be code that
runs once at the very beginning of the program, so it looks fine if the
two buffers occupy [0x1048, 0x1068).

One important thing I discovered while doing this is that when debugging
a dynamically-linked executable, breakpoints in the shared library
loader are hit before executing the _start code, and these breakpoints
may be displaced-stepped.  So it's very important that the buffer bytes
are restored properly after doing the displaced steps, otherwise the
_start code will be corrupted once we try to execute it.

Another thing that made me think about is that library constructors (as
in `__attribute__((constructor))`) run before _start.  And they are free
to spawn threads.  What if one of these threads executes a displaced
step, therefore changing the bytes at _start, while the main thread
executes _start?  That doesn't sound good and I don't know how we could
prevent it.  But this is a problem that predates the current patch.

Even when stress-testing the implementation, by making many threads do
displaced steps over and over, I didn't see a significant performance (I
confirmed that the two buffers were used by checking the "set debug
displaced" logs though).  However, this patch mostly helps make the
feature testable by anybody with an AMD64/Linux machine, so I think it's
useful.

gdb/ChangeLog:

* amd64-linux-tdep.c (amd64_linux_init_abi): Pass 2 as the
number of displaced step buffers.

Change-Id: Ia0c96ea0fcda893f4726df6fdac7be5214620112

gdb: make displaced stepping implementation capable of managing multiple buffers

The displaced_step_buffer class, introduced in the previous patch,
manages access to a single displaced step buffer.  Change it into
displaced_step_buffers (note the plural), which manages access to
multiple displaced step buffers.

When preparing a displaced step for a thread, it looks for an unused
buffer.

For now, all users still pass a single displaced step buffer, so no real
behavior change is expected here.  The following patch makes a user pass
more than one buffer, so the functionality introduced by this patch is
going to be useful in the next one.

gdb/ChangeLog:

* displaced-stepping.h (struct displaced_step_buffer): Rename
to...
(struct displaced_step_buffers): ... this.
<m_addr, m_current_thread, m_copy_insn_closure>: Remove.
<struct displaced_step_buffer>: New inner class.
<m_buffers>: New.
* displaced-stepping.c (displaced_step_buffer::prepare): Rename
to...
(displaced_step_buffers::prepare): ... this, adjust for multiple
buffers.
(displaced_step_buffer::finish):  Rename to...
(displaced_step_buffers::finish): ... this, adjust for multiple
buffers.
(displaced_step_buffer::copy_insn_closure_by_addr): Rename to...
(displaced_step_buffers::copy_insn_closure_by_addr): ... this,
adjust for multiple buffers.
(displaced_step_buffer::restore_in_ptid): Rename to...
(displaced_step_buffers::restore_in_ptid): ... this, adjust for
multiple buffers.
* linux-tdep.h (linux_init_abi): Change supports_displaced_step
for num_disp_step_buffers.
* linux-tdep.c (struct linux_gdbarch_data)
<num_disp_step_buffers>: New field.
(struct linux_info) <disp_step_buf>: Rename to...
<disp_step_bufs>: ... this, change type to
displaced_step_buffers.
(linux_displaced_step_prepare): Use
linux_gdbarch_data::num_disp_step_buffers to create that number
of buffers.
(linux_displaced_step_finish): Adjust.
(linux_displaced_step_copy_insn_closure_by_addr): Adjust.
(linux_displaced_step_restore_all_in_ptid): Adjust.
(linux_init_abi): Change supports_displaced_step parameter for
num_disp_step_buffers, save it in linux_gdbarch_data.
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust.
* alpha-linux-tdep.c (alpha_linux_init_abi): Adjust.
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Change
supports_displaced_step parameter for num_disp_step_buffers.
(amd64_linux_init_abi): Adjust.
(amd64_x32_linux_init_abi): Adjust.
* arc-linux-tdep.c (arc_linux_init_osabi): Adjust.
* arm-linux-tdep.c (arm_linux_init_abi): Adjust.
* bfin-linux-tdep.c (bfin_linux_init_abi): Adjust.
* cris-linux-tdep.c (cris_linux_init_abi): Adjust.
* csky-linux-tdep.c (csky_linux_init_abi): Adjust.
* frv-linux-tdep.c (frv_linux_init_abi): Adjust.
* hppa-linux-tdep.c (hppa_linux_init_abi): Adjust.
* i386-linux-tdep.c (i386_linux_init_abi): Adjust.
* ia64-linux-tdep.c (ia64_linux_init_abi): Adjust.
* m32r-linux-tdep.c (m32r_linux_init_abi): Adjust.
* m68k-linux-tdep.c (m68k_linux_init_abi):
* microblaze-linux-tdep.c (microblaze_linux_init_abi):
* mips-linux-tdep.c (mips_linux_init_abi): Adjust.
* mn10300-linux-tdep.c (am33_linux_init_osabi): Adjust.
* nios2-linux-tdep.c (nios2_linux_init_abi): Adjust.
* or1k-linux-tdep.c (or1k_linux_init_abi): Adjust.
* ppc-linux-tdep.c (ppc_linux_init_abi): Adjust.
* riscv-linux-tdep.c (riscv_linux_init_abi): Adjust.
* rs6000-tdep.c (struct ppc_inferior_data) <disp_step_buf>:
Change type to displaced_step_buffers.
* s390-linux-tdep.c (s390_linux_init_abi_any): Adjust.
* sh-linux-tdep.c (sh_linux_init_abi): Adjust.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Adjust.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Adjust.
* tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Adjust.
* tilegx-linux-tdep.c (tilegx_linux_init_abi): Adjust.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Adjust.

Change-Id: Ia9c02f207da2c9e1d9188020139619122392bb70

gdb: change linux gdbarch data from post to pre-init

The following patch will need to fill a field in linux_gdbarch_data
while the gdbarch is being built.  linux_gdbarch_data is currently
allocated as a post-init gdbarch data, meaning it's not possible to fill
it before the gdbarch is completely initialized.  Change it to a
pre-init gdbarch data to allow this.

The init_linux_gdbarch_data function doesn't use the created gdbarch,
it only allocates the linux_gdbarch_data structure on the gdbarch's
obstack, so the change is trivial.

gdb/ChangeLog:

* linux-tdep.c (init_linux_gdbarch_data): Change parameter to
obkstack.
(_initialize_linux_tdep): Register pre-init gdb data instead of
post-init.

Change-Id: If35ce91b6bb5435680d43b9268d811d95661644f