gdb/python: Use tp_init instead of tp_new to setup gdb.Value

The documentation suggests that we implement gdb.Value.__init__,
however, this is not currently true, we really implement
gdb.Value.__new__.  This will cause confusion if a user tries to
sub-class gdb.Value.  They might write:

  class MyVal (gdb.Value):
      def __init__ (self, val):
          gdb.Value.__init__(self, val)

  obj = MyVal(123)
  print ("Got: %s" % obj)

But, when they source this code they'll see:

  (gdb) source ~/tmp/value-test.py
  Traceback (most recent call last):
    File "/home/andrew/tmp/value-test.py", line 7, in <module>
      obj = MyVal(123)
    File "/home/andrew/tmp/value-test.py", line 5, in __init__
      gdb.Value.__init__(self, val)
  TypeError: object.__init__() takes exactly one argument (the instance to initialize)
  (gdb)

The reason for this is that, as we don't implement __init__ for
gdb.Value, Python ends up calling object.__init__ instead, which
doesn't expect any arguments.

The Python docs suggest that the reason why we might take this
approach is because we want gdb.Value to be immutable:

   https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new

But I don't see any reason why we should require gdb.Value to be
immutable when other types defined in GDB are not.  This current
immutability can be seen in this code:

  obj = gdb.Value(1234)
  print("Got: %s" % obj)
  obj.__init__ (5678)
  print("Got: %s" % obj)

Which currently runs without error, but prints:

  Got: 1234
  Got: 1234

In this commit I propose that we switch to using __init__ to
initialize gdb.Value objects.

This does introduce some additional complexity, during the __init__
call a gdb.Value might already be associated with a gdb value object,
in which case we need to cleanly break that association before
installing the new gdb value object.  However, the cost of doing this
is not great, and the benefit - being able to easily sub-class
gdb.Value seems worth it.

After this commit the first example above works without error, while
the second example now prints:

  Got: 1234
  Got: 5678

In order to make it easier to override the gdb.Value.__init__ method,
I have tweaked the definition of gdb.Value.__init__.  The second,
optional argument to __init__ is a gdb.Type, if this argument is not
present then GDB figures out a suitable type.

However, if we want to override the __init__ method in a sub-class,
and still support the default argument, it is easier to write:

  class MyVal (gdb.Value):
      def __init__ (self, val, type=None):
          gdb.Value.__init__(self, val, type)

Currently, passing None for the Type will result in an error:

  TypeError: type argument must be a gdb.Type.

After this commit I now allow the type argument to be None, in which
case GDB figures out a suitable type just as if the type had not been
passed at all.

Unless a user is trying to reinitialize a value, or create sub-classes
of gdb.Value, there should be no user visible changes after this
commit.

gdb: use try/catch around a gdb_disassembler::print_insn call

While investigating some disassembler problems I ran into this case;
GDB compiled on a 32-bit arm target, with --enable-targets=all.  Then
in GDB:

  (gdb) set architecture i386
  (gdb) disassemble 0x0,+4
  unknown disassembler error (error = -1)

This is interesting because it shows a case where the libopcodes
disassembler is returning -1 without first calling the
memory_error_func callback.  Indeed, the return from libopcodes
happens from this code snippet in i386-dis.c in the print_insn
function:

  if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
    {
      (*info->fprintf_func) (info->stream,
     _("64-bit address is disabled"));
      return -1;
    }

Notice how, prior to the return the disassembler tries to print a
helpful message out, but GDB doesn't print this message.

The reason this message goes missing is the call stack, it looks like
this:

  gdb_pretty_print_disassembler::pretty_print_insn
    gdb_disassembler::print_insn
      gdbarch_print_insn
        ...
          i386-dis.c:print_insn

When i386-dis.c:print_insn returns -1 this is handled in
gdb_disassembler::print_insn, where an exception is thrown.  However,
the actual printing of the disassembler output is done in
gdb_pretty_print_disassembler::pretty_print_insn, and is only done if
an exception is not thrown.

In this commit I change this.  The pretty_print_insn now uses
try/catch around the call to gdb_disassembler::print_insn, if we catch
an error then we first print any pending output in the instruction
buffer, before rethrowing the exception.  As a result, even if an
exception is thrown we still print any pending disassembler output to
the screen; in the above case the helpful message will now be shown.

Before my patch we might expect to see this output:

  (gdb) disassemble 0x0,+4
  Dump of assembler code from 0x0 to 0x4:
     0x0000000000000000: unknown disassembler error (error = -1)
  (gdb)

But now we see this:

  (gdb) disassemble 0x0,+4
  Dump of assembler code from 0x0 to 0x4:
     0x0000000000000000: 64-bit address is disabled
  unknown disassembler error (error = -1)

If the disassembler returns -1 without printing a helpful message then
we would still expect a change in output, something like:

  (gdb) disassemble 0x0,+4
  Dump of assembler code from 0x0 to 0x4:
     0x0000000000000000:
  unknown disassembler error (error = -1)

Which I think is still acceptable, though at this point I think a
strong case can be made that this is a disassembler bug (not printing
anything, but still returning -1).

Notice however, that the error message is always printed on a new line
now.  This is also true for the memory error case, where before we
might see this:

  (gdb) disassemble 0x0,+4
  Dump of assembler code from 0x0 to 0x4:
     0x00000000: Cannot access memory at address 0x0

We now get this:

  (gdb) disassemble 0x0,+4
  Dump of assembler code from 0x0 to 0x4:
     0x00000000:
  Cannot access memory at address 0x0

For me, I'm happy to accept this change, having the error on a line by
itself, rather than just appended to the end of the previous line,
seems like an improvement, but I'm aware others might feel
differently, so I'd appreciate any feedback.

ppc: recognize all program traps

Permanent program breakpoints (ones inserted into the code) other than
the one GDB uses for POWER (0x7fe00008) did not result in stop but
caused GDB to loop infinitely.

This was because GDB did not recognize trap instructions other than
"trap". For example, "tw 12, 4, 4" was not be recognized, causing GDB
to loop forever.

This commit fixes this by providing POWER specific hook
(gdbarch_program_breakpoint_here_p) recognizing all tw, twi, td and tdi
instructions.

Tested on Linux on PowerPC e500 and on QEMU PPC64le.

ppc: use "trap" ("tw, 31, 0, 0") as breakpoint instruction

Power ISA 3.0 B spec [1], sections 3.3.11 "Fixed-Point Trap Instructions"
and section C.6 "Trap Mnemonics" specify "tw, 31, 0, 0" (encoded as
0x7fe00008) as canonical unconditional trap instruction.

This commit changes the breakpoint instruction used by GDB from
"tw 12, r2, r2" to unconditional "trap".

[1]: https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0

bfd_section_from_shdr: Support SHT_RELR sections

If a.so contains an SHT_RELR section, objcopy a.so will fail with:

    a.so: unknown type [0x13] section `.relr.dyn'

This change allows objcopy to work.

bfd/
    * elf.c (bfd_section_from_shdr): Support SHT_RELR.

PR28673, input file 'gcov' is the same as output file

PR 28673
* ldlang.c (open_output): Use local_sym_name when checking
output against input files rather than filename.

Fix bug in source.c change

My earlier change to source.c ("Remove an xfree from add_path")
introduced a regression.  This patch fixes the problem.

gdb: make struct linespect contain vectors, not pointers to vectors

struct linespec contains pointers to vectors, instead of containing
vectors directly.  This is probably historical, when linespec_parser
(which contains a struct linespec field) was not C++-ified yet.  But it
seems easy to change the pointers to vectors to just vectors today.
This simplifies the code, we don't need to manually allocate and delete
the vectors and there's no pointer that can be NULL.

As far as I understand, there was not meaningful distinction between a
NULL pointer to vector and an empty vector.  So all NULL checks are
changed for !empty checks.

Change-Id: Ie759707da14d9d984169b93233343a86e2de9ee6

Automatic date update in version.in

Remove an xfree from add_path

This removes a temporary \0 assignment and an xfree from add_path,
replacing it with a simpler use of std::string.

gdb/linespec.c: simplify condition

We can remove the empty check: if the vector has size 1, it is obviously
not empty.  This code ended up like this because the empty check used to
be a NULL check.

Change-Id: I1571bd0228818ca93f6a6b444e9b010dc2da4c08

gdb: rename "maint agent" functions

Functions agent_eval_command and agent_command are used to implement
maintenance commands, rename them accordingly (with the maint_ prefix),
as well as the agent_command_1 helper function.

Change-Id: Iacf96d4a0a26298e8dd4648a0f38da649ea5ef61

gdb: make set_raw_breakpoint static

set_raw_breakpoint is only used in breakpoint.c, make it static.

Change-Id: I7fbeda067685309a30b88aceaf957eff7a28e310

Support AT_FXRNG and AT_KPRELOAD on FreeBSD.

FreeBSD's kernel has recently added two new ELF auxiliary vector
entries.  AT_FXRNG points to a root seed version for the kernel's
PRNG.  Userland can use this to reseed a userland PRNG after the
kernel's PRNG has reseeded.  AT_KPRELOAD is the base address of a
kernel-provided vDSO.

This change displays the proper name and description of these entries
in 'info auxv'.

include/ChangeLog:

* elf/common.h (AT_FREEBSD_FXRNG, AT_FREEBSD_KPRELOAD): Define.

Avoid extra work in global_symbol_searcher::expand_symtabs

I noticed that global_symbol_searcher::expand_symtabs always passes a
file matcher to expand_symtabs_matching.  However, if 'filenames' is
empty, then this always returns true.  It's slightly more efficient to
pass a null file matcher in this case, because that lets the "quick"
symbol implementations skip any filename checks.

Regression tested on x86-64 Fedora 34.

[gdb/testsuite] Fix options arg handling in compile_jit_elf_main_as_so

In commit 80ad340c902 ("[gdb/testsuite] use -Ttext-segment for jit-elf tests")
the following change was made:
...
 proc compile_jit_elf_main_as_so {main_solib_srcfile main_solib_binfile options} {
-    set options [concat $options debug]
+    global jit_load_address jit_load_increment
+
+    set options [list \
+       additional_flags="-DMAIN=jit_dl_main" \
+       additional_flags=-DLOAD_ADDRESS=$jit_load_address \
+       additional_flags=-DLOAD_INCREMENT=$jit_load_increment \
+       debug]
...

Before the change, the options argument was used, but after the change not
anymore.

Fix this by reverting back to using "set options [concat $options ...]".

Fixing this gets us twice the -DMAIN=jit_dl_main bit, once from a caller, and
once from compile_jit_elf_main_as_so.  Fix this by removing the bit from
compile_jit_elf_main_as_so, which makes the code similar to compile_jit_main.

Tested on x86_64-linux.

[gdb/testsuite] Fix FAIL in gdb.tui/basic.exp

On openSUSE Leap 15.2 aarch64 I ran into:
...
FAIL: gdb.tui/basic.exp: check main is where we expect on the screen
...
while this is passing on x86_64.

On x86_64-linux we have at the initial screen dump for "list -q main":
...
 0 +-/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.tui/tui-layout.c--+
 1 |       15     You should have received a copy of the GNU General Public |
 2 |       16     along with this program.  If not, see <http://www.gnu.org/|
 3 |       17                                                               |
 4 |       18  int                                                          |
 5 |       19  main ()                                                      |
 6 |       20  {                                                            |
 7 |       21    return 0;                                                  |
 8 |       22  }                                                            |
 9 |       23                                                               |
...
but on aarch64:
...
 0 +-/home/tdevries/gdb/src/gdb/testsuite/gdb.tui/tui-layout.c--------------+
 1 |       16     along with this program.  If not, see <http://www.gnu.org/|
 2 |       17                                                               |
 3 |       18  int                                                          |
 4 |       19  main ()                                                      |
 5 |       20  {                                                            |
 6 |       21    return 0;                                                  |
 7 |       22  }                                                            |
 8 |       23                                                               |
 9 |       24                                                               |
...

The cause of the diffferent placement is that we have as line number for main
on x86_64:
...
$ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
Line 20 of "tui-layout.c" starts at address 0x4004a7 <main> \
  and ends at 0x4004ab <main+4>.
...
and on aarch64 instead:
...
$ gdb -q -batch outputs/gdb.tui/basic/basic -ex "info line main"
Line 21 of "tui-layout.c" starts at address 0x4005f4 <main> \
  and ends at 0x4005f8 <main+4>.
...

Fix this by using a new source file main-one-line.c, that implements the
entire main function on a single line, in order to force the compiler to use
that line number.

Also try to do less hard-coding in the test-case.

Tested on x86_64-linux and aarch64-linux.

[gdb/tdep] Fix inferior plt calls in PIE for i386

Consider test-case test.c:
...
int main (void) {
  void *p = malloc (10);
  return 0;
}
...

When compiled to a non-PIE exec:
...
$ gcc -m32 test.c
...
the call sequence looks like:
...
 8048447:       83 ec 0c                sub    $0xc,%esp
 804844a:       6a 0a                   push   $0xa
 804844c:       e8 bf fe ff ff          call   8048310 <malloc@plt>
...
which calls to:
...
08048310 <malloc@plt>:
 8048310:       ff 25 0c a0 04 08       jmp    *0x804a00c
 8048316:       68 00 00 00 00          push   $0x0
 804831b:       e9 e0 ff ff ff          jmp    8048300 <.plt>
...
where the first insn at 0x8048310 initially jumps to the following address
0x8048316, read from the .got.plt @ 0x804a00c:
...
 804a000 0c9f0408 00000000 00000000 16830408  ................
 804a010 26830408                             &...
...

Likewise, when compiled as a PIE:
...
$ gcc -m32 -fPIE -pie test.c
...
we have this call sequence (with %ebx setup to point to the .got.plt):
...
0000055d <main>:
 579:   83 ec 0c                sub    $0xc,%esp
 57c:   6a 0a                   push   $0xa
 57e:   89 c3                   mov    %eax,%ebx
 580:   e8 6b fe ff ff          call   3f0 <malloc@plt>
...
which calls to:
...
000003f0 <malloc@plt>:
 3f0:   ff a3 0c 00 00 00       jmp    *0xc(%ebx)
 3f6:   68 00 00 00 00          push   $0x0
 3fb:   e9 e0 ff ff ff          jmp    3e0 <.plt>
...
where the insn at 0x3f0 initially jumps to following address 0x3f6, read from
the .got.plt at offset 0xc:
...
 2000 f41e0000 00000000 00000000 f6030000  ................
 2010 06040000                             ....
...

When instead doing an inferior call to malloc (with nosharedlib to force
malloc to resolve to malloc@plt rather than the functions in ld.so or libc.so)
with the non-PIE exec, we have the expected:
...
$ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
Temporary breakpoint 1 at 0x8048444

Temporary breakpoint 1, 0x08048444 in main ()
$1 = 0x804b160
...

But with the PIE exec, we run into:
...
$ gdb -q -batch a.out -ex start -ex nosharedlib -ex "p /x (void *)malloc (10)"
Temporary breakpoint 1 at 0x56c

Temporary breakpoint 1, 0x5655556c in main ()

Program received signal SIGSEGV, Segmentation fault.
0x565553f0 in malloc@plt ()
...

The segfault happens because:
- the inferior call mechanism doesn't setup %ebx
- %ebx instead is 0
- the jump to "*0xc(%ebx)" reads from memory at 0xc

Fix this by setting up %ebx properly in i386_thiscall_push_dummy_call.

Fixes this failure with target board unix/-m32/-pie/-fPIE reported in
PR28467:
...
FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2)
...

Tested on x86_64-linux, with target board unix/-m32 and unix/-m32/-fPIE/-pie.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28467

[gdb/symtab] Support -readnow during reread

When running test-case gdb.base/cached-source-file.exp with target board
readnow, we run into:
...
FAIL: gdb.base/cached-source-file.exp: rerun program (the program exited)
...

The problem is that when rereading, the readnow is ignored.

Fix this by copying the readnow handling code from symbol_file_add_with_addrs
to reread_symbols.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26800

[gdb/ada] Fix assert in ada_is_unconstrained_packed_array_type

On openSUSE Leap 42.3, with system compiler gcc 4.8.5 I run into:
...
(gdb) print u_one_two_three^M
src/gdb/gdbtypes.h:1050: internal-error: field: \
 Assertion `idx >= 0 && idx < num_fields ()' failed.^M
...

We run into trouble while doing this in
ada_is_unconstrained_packed_array_type:
...
1953          return TYPE_FIELD_BITSIZE (type, 0) > 0;
...
which tries to get field 0 from a type without fields:
...
(gdb) p type->num_fields ()
$6 = 0
...
which is the case because the type is a typedef:
...
(gdb) p type->code ()
$7 = TYPE_CODE_TYPEDEF
...

Fix this by using the type referenced by the typedef instead.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28323

Re: Add support for AArch64 EFI (efi-*-aarch64)

Commit b69c9d41e8 was broken in multiple ways regarding the realloc
of the target string, most notably in that "-little" wasn't actually
appended to the input_target or output_target.  This caused asan
errors and "FAIL: Check if efi app format is recognized".  I also
noticed that the input_target string wasn't being copied but rather
the output_target when dealing with the input target.  Fix that too.

PR 26206
* objcopy.c (convert_efi_target): Rewrite.  Allocate modified
target strings here..
(copy_main): ..rather than here.  Do handle input_target,
not output_target for input.

Error on ld output file name matching input file name

It's not foolproof, for example we don't catch output to a linker
script, to a library specified with -l, or to an element of a thin
archive.

* ldlang.c (open_output): Exit with error on output file matching
an input file.
* testsuite/ld-misc/just-symbols.exp: Adjust ld -r test to suit.

Automatic date update in version.in

gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame

This patch adds an #elif defined for PowerPC to setup the exit_0 macro.
This patch addes the needed macro definitionald logic to handle both elfV1
and elfV2.

The patch has been successfully tested on both PowerPC BE, Powerpc LE and
X86_64 with no regressions.

[gdb/testsuite] Use precise align in gdb.arch/i386-{avx,sse}.exp

Test-cases gdb.arch/i386-{avx,sse}.exp use assembly instructions that require
the memory operands to be aligned to a certain boundary, and the test-cases
use C11's _Alignas to make that happen.

The draw-back of using _Alignas is that while it does enforce a minimum
alignment, the actual alignment may be bigger, which makes the following
scenario possible:
- copy say, gdb.arch/i386-avx.c as basis for a new test-case
- run the test-case and observe a PASS
- commit the new test-case in the supposition that the test-case is correct
  and well-tested
- run later into a failure on a different test setup (which may be a setup
  where reproduction and investigation is more difficult and time-consuming),
  and find out that the specified alignment was incorrect and should have been
  updated to say, 64 bytes.  The initial PASS occurred only because the actual
  alignment happened to be greater than required.

The idea of having precise alignment as a means of having more predictable
execution which allows flushing out bugs earlier, has been filed as PR
gcc/103095.

Add a new file lib/precise-aligned-alloc.c with functions
precise_aligned_alloc and precise_aligned_dup, to support precise alignment.

Use precise_aligned_dup in aforementioned test-cases to:
- verify that the specified alignment is indeed sufficient, rather
  than too little but accidentally over-aligned.
- prevent the same type of problems in any new test-cases based on these

Tested on x86_64-linux, with both gcc and clang.

[gdb/testsuite] Fix data alignment in gdb.arch/i386-{avx,sse}.exp

When running test-case gdb.arch/i386-avx.exp with clang I ran into:
...
(gdb) PASS: gdb.arch/i386-avx.exp: set first breakpoint in main
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x000000000040052b in main (argc=1, argv=0x7fffffffd3c8) at i386-avx.c:54^M
54        asm ("vmovaps 0(%0), %%ymm0\n\t"^M
(gdb) FAIL: gdb.arch/i386-avx.exp: continue to breakpoint: \
  continue to first breakpoint in main
...

The problem is that the vmovaps insn requires an 256-bit (or 32-byte) aligned
address, and it's only 16-byte aligned:
...
(gdb) p /x $rax
$1 = 0x601030
...

Fix this by using a sufficiently aligned address, using _Alignas.

Compile using -std=gnu11 to support _Alignas.

Likewise in gdb.arch/i386-sse.exp.

Tested on x86_64-linux, with both gcc and clang.

[GOLD] PowerPC64 inline plt sequences

The fixes gold failures to handle inline PLT sequences properly.
PowerPC gold was always turning these back into direct calls due to
gsym->use_plt_offset() returning false.  This is fixed for dynamic
linking by correcting get_reference_flags, and for static linking by
overriding use_plt_offset() in relocate().  The rest of the patch
revolves around needing to create PLT entries for inline PLT calls
when statically linking (for gcc -mlongcall).  The lplt section
handled that for local symbols, now it does globals too.

* powerpc.cc (Target_powerpc::plt_off): Return proper section
for static link.
(Target_powerpc::symval_for_branch): Make public.
(Target_powerpc::make_lplt_section): Add Symbol_table* param.
Adjust all calls.
(Target_powerpc::make_local_plt_entry): Likewise.
(Target_powerpc::make_local_plt_entry): New variant for global syms.
(Powerpc_relobj::do_relocate_sections): Don't write lplt contents.
(Output_data_plt_powerpc::do_write): Write lplt contents here.
(Output_data_plt_powerpc::Output_data_plt_powerpc): Save
symbol table pointer.  Adjust all uses.
(Output_data_plt_powerpc::add_entry): Add stash parameter.  Don't
do dynamic reloc handling when no reloc section.  Save symbol
for local plt entries.
(Output_data_plt_powerpc::add_local_entry): Save symbol.
(Output_data_plt_powerpc::Local_plt_ent): New class.
(Output_data_plt_powerpc::sym_ents_): New vector.
(Target_powerpc::Scan::get_reference_flags): Return
FUNCTION_CALL|RELATIVE_REF for inline plt relocs.
(Target_powerpc::Scan::global): Make entries in lplt for inline
plt call relocation symbols.
(Target_powerpc::Relocate::relocate): Rename has_plt_offset to
use_plt_offset.  Set use_plt_offset for inline plt relocs.

ld: improve shared tests for AIX

It's now possible to refer symbols in the main program from the
shared library. However, it still impossible to have the same
overriden features between shared objects and mains than ELF,
without using the runtime linking feature which isn't yet fully
available.

ld/ChangeLog:

* testsuite/ld-shared/shared.exp: Improve XCOFF support
* testsuite/ld-shared/main.c: Likewise.
* testsuite/ld-shared/sh1.c: Likewise.
* testsuite/ld-shared/xcoff.dat: Likewise.

Automatic date update in version.in

Preserve artificial CU name in process_psymtab_comp_unit_reader

This fixes a use-after-free that Simon pointed out.
process_psymtab_comp_unit_reader was allocating an artificial name for
a CU, and then discarding it.  However, this name was preserved in the
cached file_and_directory.  This patch arranges for the allocated name
to be preserved there.

sim: include ansidecl.h when needed

Avoid implicit include deps with this to help untangle sim headers
so we can get rid of arch-specific sim-main.h.

sim: include stdint.h when needed

Avoid implicit include deps with this to help untangle sim headers
so we can get rid of arch-specific sim-main.h.

sim: include stdarg.h when used

Avoid implicit include deps with this to help untangle sim headers
so we can get rid of arch-specific sim-main.h.

sim: reorder header includes

We're including system headers after local headers in a bunch of
places, but this leads to conflicts when our local headers happen
to define symbols that show up in the system headers.

Use the more standard order of:
* config.h (via defs.h)
* system headers
* local library headers (e.g. bfd & libiberty)
* sim specific headers

gdbsupport: fix memory leak in create_file_handler when re-using file handler

ASan made me notice a memory leak, where the memory tied to the file
handle name string wasn't freed.  When register a file handler with an
fd that is already registered, we re-use the file_handler object, so we
ended up creating a new std::string object and overwriting the
file_handler::name pointer, without free-ing the old std::string.

Fix this by allocating file_handler with new, deleting it with
delete, and making file_handler::name not a pointer.

Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43

Automatic date update in version.in

sim: moxie: hoist dtb rules up to common builds

These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.

sim: m68hc11: delete unused profile flags

These were moved to the common configure script a while ago and have
the same default as these, so just delete it.

sim: msp430: delete redundant comments & settings

These were copied from the example docs, so aren't adding any value.

sim: erc32: drop old configure target

There is no configure script in here anymore to regenerate.

sim: m32c/rl78: drop redundant -Wall settings

We already turn these on in the configure script.

Cache the result of find_file_and_directory

This changes the DWARF reader to cache the result of
find_file_and_directory.  This is not especially important now, but it
will help the new DWARF indexer.

Move file_and_directory to new file and C++-ize

This moves file_and_directory to a new file, and then C++-izes it --
replacing direct assignments with methods, and arranging for it to own
any string that must be computed.  Finally, the CU's objfile will only
be used on demand; this is an important property for the new DWARF
indexer's parallel mode.

Remove Irix case from find_file_and_directory

find_file_and_directory has a special case for the Irix 6.2 compiler.
Since this is long obsolete, this patch removes it.

sim: frv: split up testsuite a bit

Running frv's allinsn in serial is quite slow due to the sheer number
of tests it contains.  By splitting it up and running in parallel, the
execution time on my system goes from ~100sec to ~60sec.

gdb: don't show deprecated aliases

I don't think it's very useful to show deprecated aliases to the
user.  It encourages the user to use them, when the goal is the
opposite.

For example, before:

    (gdb) help set index-cache enabled
    set index-cache enabled, set index-cache off, set index-cache on
      alias set index-cache off = set index-cache enabled off
      alias set index-cache on = set index-cache enabled on
    Enable the index cache.
    When on, enable the use of the index cache.

    (gdb) help set index-cache on
    Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
    Use 'set index-cache enabled on'.

    set index-cache enabled, set index-cache off, set index-cache on
      alias set index-cache off = set index-cache enabled off
      alias set index-cache on = set index-cache enabled on
    Enable the index cache.
    When on, enable the use of the index cache.

After:

    (gdb) help set index-cache enabled
    Enable the index cache.
    When on, enable the use of the index cache.
    (gdb) help set index-cache on
    Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated.
    Use 'set index-cache enabled on'.

    Enable the index cache.
    When on, enable the use of the index cache.

Change-Id: I989b618a5ad96ba975367e9d16db95523cd57a4c

gdb/testsuite: fix two "maint info line-table"-related tests

Commit 92228a334ba2 ("gdb: small "maintenance info line-table"
readability improvements") change the output format of "maint info
line-table" slightly, adding some empty lines between each
line-table.  This causes two tests to start failing, update them to
account for those empty lines.

Change-Id: I9d33a58fce3e860ba0554b25f5582e8066a5c519

gdb: revert one array_view copy change in ada-lang.c

Commit 4bce7cdaf481 ("gdbsupport: add array_view copy function") caused
an internal error when running gdb.ada/packed_array_assign.exp:

    print pra(1) := pr^M
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.^M

I am not sure what's the root cause of this, whether it is a GDB bug
exposed by using the array_view copy function or not.  Back out the
change that triggers the internal error for now, while we investigate
it.

Change-Id: I055ab14143e4cfd3ca7ce8f4855c6c3c05db52a7

bfd: unify header generation rules

The logic between these rules are extremely similar, so unify them
into a single variable.

bfd: move header updates up a directory

The rules for rebuilding the bfd headers live in the doc/ subdir
(most likely) because they rely on the chew & related tools.  But
we can collapse them into the main Makefile while keeping the tools
in the doc subdir easily enough.  This makes the code simpler and
allows for rebuilding them in parallel.

Also add automake silent rule support while we're here.

bfd: convert bfdver.h to silent automake rules

Automatic date update in version.in

gdb: small "maintenance info line-table" readability improvements

 - separate each entry with a newline, to visually separate them
 - style filenames with the filename style
 - print the name of the compunit_symtab

A header now looks like this, with the compunit_symtab name added (and
the coloring, but you can't really see it here):

    objfile: /home/simark/build/babeltrace/src/cli/.libs/babeltrace2 ((struct objfile *) 0x613000005980)
    compunit_symtab: babeltrace2-cfg-cli-args.c ((struct compunit_symtab *) 0x62100da1ed10)
    symtab: /usr/include/glib-2.0/glib/gdatetime.h ((struct symtab *) 0x62100d9ee530)
    linetable: ((struct linetable *) 0x0):

Change-Id: Idc23e10aaa66e2e692adb0a6a74144f72c4fa1c7

gdb: change some alias functions parameters to const-reference

Now that we use intrusive list to link aliases, it becomes easier to
pass cmd_list_element arguments by const-reference rather than by
pointer to some functions, change a few.

Change-Id: Id0df648ed26e9447da0671fc2c858981cda31df8

gdb: use intrusive_list for cmd_list_element aliases list

Change the manually-implemented linked list to use intrusive_list.  This
is not strictly necessary, but it makes the code much simpler.

Change-Id: Idd08090ebf2db8bdcf68e85ef72a9635f1584ccc

gdb: trivial changes to use array_view

Change a few relatively obvious spots using value contents to propagate
the use array_view a bit more.

Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15

gdb: make extract_integer take an array_view

I think it would make sense for extract_integer, extract_signed_integer
and extract_unsigned_integer to take an array_view.  This way, when we
extract an integer, we can validate that we don't overflow the buffer
passed by the caller (e.g. ask to extract a 4-byte integer but pass a
2-byte buffer).

 - Change extract_integer to take an array_view
 - Add overloads of extract_signed_integer and extract_unsigned_integer
   that take array_views.  Keep the existing versions so we don't
   need to change all callers, but make them call the array_view
   versions.

This shortens some places like:

  result = extract_unsigned_integer (value_contents (result_val).data (),
     TYPE_LENGTH (value_type (result_val)),
     byte_order);

into

  result = extract_unsigned_integer (value_contents (result_val), byte_order);

value_contents returns an array view that is of length
`TYPE_LENGTH (value_type (result_val))` already, so the length is
implicitly communicated through the array view.

Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95

gdbsupport: add array_view copy function

An assertion was recently added to array_view::operator[] to ensure we
don't do out of bounds accesses.  However, when the array_view is copied
to or from using memcpy, it bypasses that safety.

To address this, add a `copy` free function that copies data from an
array view to another, ensuring that the destination and source array
views have the same size.  When copying to or from parts of an
array_view, we are expected to use gdb::array_view::slice, which does
its own bounds check.  With all that, any copy operation that goes out
of bounds should be caught by an assertion at runtime.

copy is implemented using std::copy and std::copy_backward, which, at
least on libstdc++, appears to pick memmove when copying trivial data.
So in the end there shouldn't be much difference vs using a bare memcpy,
as we do right now.  When copying non-trivial data, std::copy and
std::copy_backward assigns each element in a loop.

To properly support overlapping ranges, we must use std::copy or
std::copy_backward, depending on whether the destination is before the
source or vice-versa.  std::copy and std::copy_backward don't support
copying exactly overlapping ranges (where the source range is equal to
the destination range).  But in this case, no copy is needed anyway, so
we do nothing.

The order of parameters of the new copy function is based on std::copy
and std::copy_backward, where the source comes before the destination.

Change a few randomly selected spots to use the new function, to show
how it can be used.

Add a test for the new function, testing both with arrays of a trivial
type (int) and of a non-trivial type (foo).  Test non-overlapping
ranges as well as three kinds of overlapping ranges: source before dest,
dest before source, and dest == source.

Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03

gdb: change store_waitstatus to return a target_waitstatus by value

store_waitstatus is basically a translation function between a status
integer and an equivalent target_waitstatus object.  It would make sense
for it to take the integer as a parameter and return the
target_waitstatus by value.  Do that, and rename to
host_status_to_waitstatus.  Users can then do:

  ws = host_status_to_waitstatus (status)

which does the right thing, given the move constructor of
target_waitstatus.

Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b

gdb: return *this in target_waitstatus setters

While playing with some code creating target_waitstatus objects, I was
mildly annoyed by the fact that we can't just return a new
target_waitstatus object.  We have to do:

    target_waitstatus ws;
    ws.set_exited (123);
    return ws;

Make the setters return the "this" object as a reference, such that it's
possible to do:

    return target_waitstatus ().set_exited (123);

I initially thought of adding static creation functions, which you would
use like:

    return target_waitstatus::make_exited (123);

However, making the setters return a reference to the object achieves
pretty much the same thing, with less new code.

Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147

gdb: make saved_filename an std::string

Make this variable an std::string, avoiding manual memory management.

Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947

aarch64: Fix uninitialised memory

AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B
are not paired with an error string, but we had an assert that the
error was nonnull.  Previously this assert was testing uninitialised
memory and so could pass or fail arbitrarily.

opcodes/
* aarch64-opc.c (verify_mops_pme_sequence): Initialize the error
field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and
AARCH64_OPDE_A_SHOULD_FOLLOW_B.
* aarch64-dis.c (print_verifier_notes): Move assert.

gdb: make value_subscripted_rvalue static

The function value_subscripted_rvalue is only used in valarith.c, so
lets make it a static function.

There should be no user visible change after this commit.

gdb/testsuite: give a test a real name

A test in gdb.python/py-send-packet.exp added in this commit:

  commit 24b2de7b776f8f23788d855b1eec290c6e208821
  Date:   Tue Aug 31 14:04:36 2021 +0100

      gdb/python: add gdb.RemoteTargetConnection.send_packet

included a large amount of binary data in the command sent to GDB.  As
this test didn't have a real test name the binary data was included in
the gdb.sum file.  The contents of the binary data could change
between different runs of GDB, and this makes comparing results
harder.

This commit gives the test a real test name.

gdb/remote: fix use after free bug

This commit:

  commit 288712bbaca36bff6578bc839ebcdc3707662f81
  Date:   Mon Nov 22 15:16:27 2021 +0000

      gdb/remote: use scoped_restore to control starting_up flag

introduced a use after free bug.  The scoped restore added in the
above commit resets a flag within a remote_target's remote_state
object.

However, in some situations, the remote_target can be unpushed before
the error is thrown.  If the only reference to the target is the one
in the target stack, then unpushing the target will cause the
remote_target to be deleted, which, in turn, will delete the
remote_state object.  The scoped restore will then try to reset the
flag within a deleted object.

This problem was caught in the gdb.server/server-connect.exp test,
which, when run with the address sanitizer enabled, highlights the
write after free bug described above.

This commit resolves this issue by adding a new class specifically for
the purpose of managing the starting_up flag.  As well as setting, and
then clearing the starting_up flag, this new class increments, and
then decrements the reference count on the remote_target object.  This
prevents the remote_target from being deleted until after the flag has
been reset.

The gdb.server/server-connect.exp now runs cleanly with the address
sanitizer enabled.

libctf: workaround automake bug with conditional info pages

It looks like automake makes assumptions about its ability to build info
pages based on the GNU standard behavior of shipping info pages with the
distributions.  So even though the info pages were conditionalized, and
automake disabled some of the targets, it was still creeping in by way
of unconditional INFO_DEPS settings.

We can workaround this by adding a stub target for the info page when
building info pages are disabled.  This tricks automake into disabling
its own extended generation target.  I'll follow up with the automake
folks to see what they think.

Add myself and Zhensong Liu as the LoongArch port maintainer.

Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"

This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41.
The bpf sim doesn't work with a 32-bit bfd after all.

Automatic date update in version.in

gdb: remove unexpected xstrdup in _initialize_maint_test_settings

That xstrdup is not correct, since we are assigning an std::string.  The
result of xstrdup is used to initialize the string, and then lost
forever.  Remove it.

Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335

Fix illegal memory access whilst parsing corrupt DWARF debug information.

PR 28645
* dwarf.c (process_cu_tu_index): Add test for overruning section
whilst processing slots.

[gdb/tdep] Fix avx512 -m32 support in gdbserver

PR27257 reports a problem that can be reproduced as follows:
- use x86_64 machine with avx512 support
- compile a hello world with -m32 to a.out
- start a gdbserver session with a.out
- use gdb to connect to the gdbserver session

This makes us run into:
...
Listening on port 2346
Remote debugging from host ::1, port 34940
src/gdbserver/regcache.cc:257: \
  A problem internal to GDBserver has been detected.
Unknown register zmm16h requested
...

The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
register zmm16h in the register cache.

To understand how this happens, first some background.

SSE has 16 128-bit wide xmm registers.

AVX extends the SSE registers set as follows:
- it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
  registers.

AVX512 extends the AVX register set as follows:
- it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
  registers.
- it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
  xmm subregisters added as well)

However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.

The problem we're running into is that gdbserver/i387-fp.cc uses these
constants to describe the size of the register file:
...
static const int num_avx512_zmmh_low_registers = 16;
static const int num_avx512_zmmh_high_registers = 16;
static const int num_avx512_ymmh_registers = 16;
static const int num_avx512_xmm_registers = 16;
...
which are all incorrect for the 32-bit case.

Fix this by replacing the constants with variables that have the appropriate
values in 64-bit and 32-bit mode.

Tested on x86_64-linux with native and unix/-m32.

gdb/testsuite: update tests looking for "DWARF 2" debug format

Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
debugformat field") changes the debug format string in "info source" to
show the actual DWARF version, rather than always show "DWARF 2".

However, it failed to consider that some tests checked for the "DWARF 2"
string to see if the test program is compiled with DWARF debug
information.  Since everything is compiled with DWARF 4 or 5 nowadays,
that changed the behavior of those tests.  Notably, it prevent the
tests using skip_inline_var_tests to run.

Grep through the testsuite for "DWARF 2" and change all occurrences I
could find to use "DWARF [0-9]" instead (that string is passed to TCL's
string match).

Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885

(PPC64) fix handling of fixed-point values when using "return" command

In the gdb.ada/fixed_points_function.exp testcase, we have the following
Ada code...

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

... used as follow:

   F1 : FP1_Type := 1.0;
   F1 := Call_FP1 (F1);

The testcase, among other things, verifies that "return" works
properly as follow:

    | (gdb) return 1.0
    | Make pck.call_fp1 return now? (y or n) y
    | [...]
    | 9          F1 := Call_FP1 (F1);
    | (gdb) next
    | (gdb) print f1
    | $1 = 0.0625

The output of the last command shows that we returned the wrong
value. The value printed gives a clue about the problem, since
it is 1/16th of the value we expected, where 1/16 is FP1_Type's
scaling factor.

The problem, here, comes from the fact that the function
handling return values for base types (ppc64_sysv_abi_return_value_base)
writes the return value using unpack_long which, upon seeing that
the value being unpacked is a fixed point type, applies the scaling
factor, to get the integer-representation of our fixed-point value
(similar to what it does with floats, for instance).

So, the fix consists in teaching ppc64_sysv_abi_return_value_base
about fixed-point types, and to avoid the unwanted application
of the scaling factor.

Note that the "finish" function, on the other hand, does not
suffer from this issue, simply becaue the value returned by
the function is read from register without the use of a type,
thus avoiding an unwanted application of a scaling factor.

No test added, as this change is already tested by
gdb.ada/fixed_points_function.exp.

Co-Authored-By: Tristan Gingold <gingold@adacore.com>

(RISCV) fix handling of fixed-point type return values

This commit adds support for TYPE_CODE_FIXED_POINT types for
"finish" and "return" commands.

Consider the following Ada code...

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

... used as follow:

   F1 : FP1_Type := 1.0;
   F1 := Call_FP1 (F1);

"finish" currently behaves as follow:

    | (gdb) finish
    | [...]
    | Value returned is $1 = 0

We expect the returned value to be "1".

Similarly, "return" makes the function return the wrong value:

    | (gdb) return 1.0
    | Make pck.call_fp1 return now? (y or n) y
    | [...]
    | 9          F1 := Call_FP1 (F1);
    | (gdb) next
    | (gdb) print f1
    | $1 = 0.0625

(we expect it to print "1" instead).

This problem comes from the handling of integral return values
when the return value is actually fixed point type. Our type
here is actually a range of a fixed point type, but the same
principles should also apply to pure fixed-point types. For
the record, here is what the debugging info looks like:

 <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
    <239>   DW_AT_lower_bound : -16
    <23a>   DW_AT_upper_bound : 16
    <23b>   DW_AT_name        : pck__fp1_type
    <23f>   DW_AT_type        : <0x248>

 <1><248>: Abbrev Number: 4 (DW_TAG_base_type)
    <249>   DW_AT_byte_size   : 1
    <24a>   DW_AT_encoding    : 13      (signed_fixed)
    <24b>   DW_AT_binary_scale: -4
    <24c>   DW_AT_name        : pck__Tfp1_typeB
    <250>   DW_AT_artificial  : 1

... where the scaling factor is 1/16.

Looking at the "finish" command, what happens is that riscv_arg_location
determines that our return value should be returned by parameter using
an integral convention (via builtin type long). And then,
riscv_return_value uses a cast to that builtin type long to
store the value of into a buffer with the right register size.
This doesn't work in our case, because the underlying value
returned by the function is unscaled, which means it is 16,
and thus the cast is like doing:

   arg_val = (FP1_Type) 16

... In other words, it is trying to create an FP1_Type enty whose
value is 16. Applying the scaling factor, that's 256, and because
the size of FP1_Type is 1 byte, we overflow and thus it ends up
being zero.

The same happen with the "return" function, but the other way around.

The fix consists in handling fixed-point types separately from
integral types.

(ARM/fixed-point) wrong value shown by "finish" command:

Consider the following Ada code:

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   FP1_Arg : FP1_Type := 0.0;

   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

After having stopped inside function Call_FP1 as follow:

    Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5
    5             FP1_Arg := F;

Returning from that function call using "finish" should show
that the function return "1.0" (the same value as was passed
as an argument). However, this is not the case:

    (gdb) finish
    Run till exit from #0  pck.call_fp1 (f=1)
    [...]
    9          F1 := Call_FP1 (F1);
    Value returned is $1 = 0

This patch enhances the extraction of the return value to know about
fixed point types.

(Ada/AArch64) fix fixed point argument passing in inferior funcall

Consider the following code:

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary

   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      return F;
   end Call_FP1;

When the default in GCC is to generate proper DWARF info for fixed point
types, then in gdb, printing the result of a call to call_fp1 with a
decimal parameter leads to:

  (gdb) p call_fp1(0.5)
  $1 = 0

The displayed value is wrong, and we actually expected:

  (gdb) p call_fp1(0.5)
  $1 = 0.5

What happened is that our fixed point type parameter got promoted to a
32bit integer because we detected that the length of that object was less
than 4 bytes. The compiler does not perform this promotion and therefore
GDB should not either.

This patch fixes the behavior described above.

Implement 'task apply'

This adds a 'task apply' command, which is the Ada tasking analogue of
'thread apply'.  Unlike 'thread apply', it doesn't offer the
'ascending' flag; but otherwise it's essentially the same.

Add "task" keyword to the "watch" command

Breakpoints in gdb can be made specific to an Ada task using the
"task" qualifier.  This patch applies this same idea to watchpoints.

aarch64: Update gas/NEWS for recent changes

gas/
* NEWS: Mention support for Armv8.8-A and for new system registers.

aarch64: Add BC instruction

This patch adds support for the Armv8.8-A BC instruction.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/BC-cond--Branch-Consistent-conditionally-?lang=en]

include/
* opcode/aarch64.h (AARCH64_FEATURE_HBC): New macro.
(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_HBC.

opcodes/
* aarch64-tbl.h (aarch64_feature_hbc): New variable.
(HBC, HBC_INSN): New macros.
(aarch64_opcode_table): Add BC.C.
* aarch64-dis-2.c: Regenerate.

gas/
* doc/c-aarch64.texi: Document +hbc.
* config/tc-aarch64.c (aarch64_features): Add "hbc".
* testsuite/gas/aarch64/hbc.s, testsuite/gas/aarch64/hbc.d: New test.
* testsuite/gas/aarch64/hbc-invalid.s,
testsuite/gas/aarch64/hbc-invalid.l,
testsuite/gas/aarch64/hbc-invalid.d: New test.

aarch64: Enforce P/M/E order for MOPS instructions

The MOPS instructions should be used as a triple, such as:

       cpyfp [x0]!, [x1]!, x2!
       cpyfm [x0]!, [x1]!, x2!
       cpyfe [x0]!, [x1]!, x2!

The registers should also be the same for each writeback operand.
This patch adds a warning for code that doesn't follow this rule,
along similar lines to the warning that we already emit for
invalid uses of MOVPRFX.

include/
* opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E)
(C_SCAN_MOPS_PME): New macros.
(AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind.
(AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise.
(aarch64_operand_error): Make each data value a union between
an int and a string.

opcodes/
* aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags.
(MOPS_SET_OP1_OP2_INSN): Likewise.
* aarch64-opc.c (set_out_of_range_error): Update after change to
aarch64_operand_error.
(set_unaligned_error, set_reg_list_error): Likewise.
(init_insn_sequence): Use a 3-instruction sequence for
MOPS P instructions.
(verify_mops_pme_sequence): New function.
(verify_constraints): Call it.
* aarch64-dis.c (print_verifier_notes): Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.

gas/
* config/tc-aarch64.c (operand_mismatch_kind_names): Add entries
for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
(operand_error_higher_severity_p): Check that
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B
come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR;
their relative order is not significant.
(record_operand_error_with_data): Update after change to
aarch64_operand_error.
(output_operand_error_record): Likewise.  Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
* testsuite/gas/aarch64/mops_invalid_2.s,
testsuite/gas/aarch64/mops_invalid_2.d,
testsuite/gas/aarch64/mops_invalid_2.l: New test.

aarch64: Add support for +mops

This patch adds support for FEAT_MOPS, an Armv8.8-A extension
that provides memcpy and memset acceleration instructions.

I took the perhaps controversial decision to generate the individual
instruction forms using macros rather than list them out individually.
This becomes useful with a follow-on patch to check that code follows
the correct P/M/E sequence.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en]

include/
* opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro.
(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS.
(AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd.
(AARCH64_OPND_MOPS_ADDR_Rs): Likewise.
(AARCH64_OPND_MOPS_WB_Rn): Likewise.

opcodes/
* aarch64-asm.h (ins_x0_to_x30): New inserter.
* aarch64-asm.c (aarch64_ins_x0_to_x30): New function.
* aarch64-dis.h (ext_x0_to_x30): New extractor.
* aarch64-dis.c (aarch64_ext_x0_to_x30): New function.
* aarch64-tbl.h (aarch64_feature_mops): New feature set.
(aarch64_feature_mops_memtag): Likewise.
(MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN)
(MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN)
(MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN)
(MOPS_SET_INSN): New macros.
(aarch64_opcode_table): Add MOPS instructions.
(aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
* aarch64-opc.c (aarch64_print_operand): Handle
AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and
AARCH64_OPND_MOPS_WB_Rn.
(verify_three_different_regs): New function.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.

gas/
* doc/c-aarch64.texi: Document +mops.
* config/tc-aarch64.c (parse_x0_to_x30): New function.
(parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
(aarch64_features): Add "mops".
* testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test.
* testsuite/gas/aarch64/mops_invalid.s,
* testsuite/gas/aarch64/mops_invalid.d,
* testsuite/gas/aarch64/mops_invalid.l: Likewise.

aarch64: Add Armv8.8-A system registers

Armv8.8-A defines two new system registers: allint and icc_nmiar1_el1.
Both of them were previously unmapped.  allint supports a 0/1 immediate.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ALLINT--All-Interrupt-Mask-Bit?lang=en]
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ICC-NMIAR1-EL1--Interrupt-Controller-Non-maskable-Interrupt-Acknowledge-Register-1?lang=en]

opcodes/
* aarch64-opc.c (SR_V8_8): New macro.
(aarch64_sys_regs): Add allint and icc_nmiar1_el1.
(aarch64_pstatefields): Add allint.

gas/
* testsuite/gas/aarch64/armv8_8-a-sysregs.s,
* testsuite/gas/aarch64/armv8_8-a-sysregs.d: New test.
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.s,
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.l,
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.d: New test.

aarch64: Add id_aa64isar2_el1

Armv8.8-A defines a read-only system register called id_aa64isar2_el1.
The register was previously RES0 and should therefore be accepted
at all architecture levels.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en]

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1.

gas/
* testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly.
* testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise.
* testsuite/gas/aarch64/sysreg.s: Test reads from
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg.d: Update accordingly.

aarch64: Add support for Armv8.8-A

This patch adds skeleton support for -march=armv8.8-a, testing only
that it correctly inherits from armv8.7-a.

include/
* opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro.
(AARCH64_ARCH_V8_8): Likewise.

gas/
* doc/c-aarch64.texi: Document armv8.8-a.
* config/tc-aarch64.c (aarch64_archs): Add armv8-8-a
* testsuite/gas/aarch64/v8-8-a.s,
* testsuite/gas/aarch64/v8-8-a.d: New test.

aarch64: Provide line info for unclosed sequences

We warn about MOVPRFX instructions that have no following
instruction.  This patch adds a line number to the message,
which is useful if the assembly code has multiple text sections.

The new code is unconditional since OBJ_ELF is always defined
for aarch64.

gas/
* config/tc-aarch64.h (aarch64_segment_info_type): Add last_file
and last_line.
* config/tc-aarch64.c (now_instr_sequence): Delete.
(force_automatic_sequence_close): Provide a line number when
reporting unclosed sequences.
(md_assemble): Record the location of the instruction in
tc_segment_info.
* testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error
message.
* testsuite/gas/aarch64/sve-movprfx_7.l: Likewise.
* testsuite/gas/aarch64/sve-movprfx_8.l: Likewise.

aarch64: Tweak insn sequence code

libopcodes has some code to check constraints across sequences
of consecutive instructions.  It was added to support MOVPRFX
sequences but is going to be useful for the Armv8.8-A MOPS
feature as well.

Currently the structure has one field to record the instruction
that started a sequence and another to record the remaining
instructions in the sequence.  It's more convenient for the
MOPS code if we put the instructions into a single array instead.

No functional change intended.

include/
* opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns
and current_insns with num_added_insns and num_allocated_insns.

opcodes/
* aarch64-opc.c (add_insn_to_sequence): New function.
(init_insn_sequence): Update for new aarch64_instr_sequence layout.
Add the first instruction to the inst array.
(verify_constraints): Update for new aarch64_instr_sequence layout.
Don't add the last instruction to the array.

aarch64: Add maximum immediate value to aarch64_sys_reg

The immediate form of MSR has a 4-bit immediate field (in CRm).
However, many forms of MSR require a smaller immediate.  These cases
are identified by value in operand_general_constraint_met_p,
but they're now the common case rather than the exception.

This patch therefore adds the maximum value to the sys_reg
description and gets the range from there.  It also enforces
the minimum of 0, which avoids a situation in which:

  msr dit, #2

would give the expected:

  Error: immediate value out of range 0 to 1

whereas:

  msr dit, #-1

would give:

  Error: immediate value out of range 0 to 15

(from the later UIMM4 checking).

Also:

- we were reporting the first error above against the wrong operand
- TCO takes a single-bit immediate, but we previously allowed
  all 16 values.
  [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en]

opcodes/
* aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros.
* aarch64-opc.c (operand_general_constraint_met_p): Read the
maximum MSR immediate value from aarch64_pstatefields.
(aarch64_pstatefields): Add the maximum immediate value
for each register.

gas/
* testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1
rather than 8 for the TCO test.
* testsuite/gas/aarch64/sysreg-4.d: Update accordingly.
* testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number
in MSR immediate error messages.
* testsuite/gas/aarch64/diagnostic.l: Likewise.
* testsuite/gas/aarch64/pan-illegal.l: Likewise.
* testsuite/gas/aarch64/ssbs-illegal1.l: Likewise.
* testsuite/gas/aarch64/illegal-sysreg-4b.s,
* testsuite/gas/aarch64/illegal-sysreg-4b.d,
* testsuite/gas/aarch64/illegal-sysreg-4b.l: New test.

Allow the --visualize-jumps feature to work with the AVR disassembler.

* avr-dis.c (avr_operand); Pass in disassemble_info and fill
in insn_type on branching instructions.

gdb, include: replace pragmas with DIAGNOSTIC macros, fix build with g++ 4.8

When introducing this code, I forgot that we had some macros for this.
Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros,
provided by include/diagnostics.h.

In diagnostics.h:

 - Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level.
 - Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for
   both gcc and clang.

Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and
DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these
errors:

      CXX    ada-tasks.o
    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks():
    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch]
       switch (data->known_tasks_kind)
              ^

Because of the POP, the diagnostic should go back to being disabled,
since it was disabled in the beginning, but that's not what we see
here.  Versions of GCC >= 5 compile correctly.

Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5.

Note that this code (already as it exists in master today) enables
-Wswitch at the error level even if --disable-werror is passed.  It
shouldn't be a problem, as it's not like a new enumerator will appear
out of nowhere and cause a build error if building with future
compilers.  Still, for correctness, we would ideally want to ask the
compiler to enable -Wswitch at its default level (as if the user had
passed -Wswitch on the command-line).  There doesn't seem to be a way to
do this.

Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d

gas: re-generate configure

When configuring gas, I get:

  config.status: error: cannot find input file: `doc/Makefile.in'

This is because configure is out-of-date, re-generate it.

Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498

libctf: re-generate configure

When configuring libctf, I get:

  config.status: error: cannot find input file: `doc/Makefile.in'

This is because configure is out-of-date, re-generate it.

Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169

x86: Skip __[start|stop]_SECNAME for --gc-sections -z start-stop-gc

Don't convert memory load to immediate load on __start_SECNAME and
__stop_SECNAME for --gc-sections -z start-stop-gc if all SECNAME
sections been garbage collected.

bfd/

PR ld/27491
* elf32-i386.c (elf_i386_convert_load_reloc): Skip __start_SECNAME
and __stop_SECNAME for --gc-sections -z start-stop-gc if the input
section been garbage collected.
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise.
* elfxx-x86.h (elf_x86_start_stop_gc_p): New function.

ld/
PR ld/27491
* testsuite/ld-i386/i386.exp: Run PR ld/27491 tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr27491-1.s: New file.
* testsuite/ld-i386/pr27491-1a.d: Likewise.
* testsuite/ld-i386/pr27491-1b.d: Likewise.
* testsuite/ld-i386/pr27491-1c.d: Likewise.
* testsuite/ld-i386/pr27491-2.d: Likewise.
* testsuite/ld-i386/pr27491-2.s: Likewise.
* testsuite/ld-i386/pr27491-3.d: Likewise.
* testsuite/ld-i386/pr27491-3.s: Likewise.
* testsuite/ld-i386/pr27491-4.d: Likewise.
* testsuite/ld-i386/pr27491-4a.s: Likewise.
* testsuite/ld-i386/pr27491-4b.s: Likewise.
* testsuite/ld-x86-64/pr27491-1.s: Likewise.
* testsuite/ld-x86-64/pr27491-1a.d: Likewise.
* testsuite/ld-x86-64/pr27491-1b.d: Likewise.
* testsuite/ld-x86-64/pr27491-1c.d: Likewise.
* testsuite/ld-x86-64/pr27491-2.d: Likewise.
* testsuite/ld-x86-64/pr27491-2.s: Likewise.
* testsuite/ld-x86-64/pr27491-3.d: Likewise.
* testsuite/ld-x86-64/pr27491-3.s: Likewise.
* testsuite/ld-x86-64/pr27491-4.d: Likewise.
* testsuite/ld-x86-64/pr27491-4a.s: Likewise.
* testsuite/ld-x86-64/pr27491-4b.s: Likewise.

bfd: delete unused proto settings

These have been around for decades but don't appear to be used, and
trying to build them (e.g. `make archive.p archive.ip`) doesn't work,
so just delete it all.

gas: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

libctf: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

gdb: use actual DWARF version in compunit's debugformat field

The "info source" command, with a DWARF-compile program, always show
that the debug info is "DWARF 2":

    (gdb) info source
    Current source file is test.c
    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
    Contains 2 lines.
    Source language is c.
    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
    Compiled with DWARF 2 debugging format.
    Includes preprocessor macro info.

Change it to display the actual DWARF version:

    (gdb) info source
    Current source file is test.c
    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
    Contains 2 lines.
    Source language is c.
    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
    Compiled with DWARF 5 debugging format.
    Includes preprocessor macro info.

The comp_unit_head::version field is guaranteed to be between 2 and 5,
thanks to the check in read_comp_unit_head.  So we can still use static
strings to pass to record_debugformat, and keep it efficient.

In the future, when somebody will update GDB to support DWARF 6, they'll
hit this assert and have to update this code.

Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172

elf: Discard input .note.gnu.build-id sections

1. Discard input .note.gnu.build-id sections.
2. Clear the build ID field before writing.
3. Use bfd_make_section_anyway_with_flags to create the output
.note.gnu.build-id section.

PR ld/28639
* ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
sections, excluding the first one.
(write_build_id): Clear the build ID field before writing.
(ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
to create the output .note.gnu.build-id section.
* testsuite/ld-elf/build-id.exp: New file.
* testsuite/ld-elf/pr28639a.rd: Likewise.
* testsuite/ld-elf/pr28639b.rd: Likewise.
* testsuite/ld-elf/pr28639c.rd: Likewise.
* testsuite/ld-elf/pr28639d.rd: Likewise.

Automatic date update in version.in