ppc-opc: sync instructions

all: sync recent ff/pi/lf updates

svp64: mark RA0 operands; introduce RT0 operand

ppc: support ffadds instruction

ppc: support fdmadds instruction

ppc: support ffnmadds instruction

ppc: support ffnmsubs instruction

ppc: support ffmadds instruction

ppc: support ffmsubs instruction

ppc: support minmax aliases

ppc: support minmax instruction

ppc: support maddedus instruction

ppc: support dsrd instruction

ppc: support dsld instruction

ppc-opc.c: place new instructions at SFFS level

svp64: sync specifiers

ppc/svp64: support optional operands disassembly

ppc/svp64: disassemble branch mode

ppc/svp64: disassemble CR op mode

ppc/svp64: disassemble ld/st idx mode

ppc/svp64: disassemble ld/st imm mode

ppc/svp64: disassemble normal mode

ppc/svp64: disassemble SVP64 operands

ppc/svp64: disassemble SVP64 name

ppc/svp64: obtain SVP64 disassembly context

ppc/svp64: share SVP64 context via libopcodes

ppc/svp64: introduce SVP64 opcode lookup

ppc: decouple print_insn_powerpc_opcode routine

ppc/svp64: reuse md_parse_name in md_operand

ppc/svp64: introduce alias for 1<<%r3 predicate

ppc/svp64: allow predicate macro expansion

ppc/svp64: introduce SVP64 name parser

ppc/svp64: allow w/dw/sw macro expansion

ppc/svp64: remap operands and build instructions

ppc/svp64: support SVP64 vectors

ppc: refactor assembly logic

ppc/svp64: validate and fix modes

ppc/svp64: validate SVP64 context

ppc/svp64: support crm mode

ppc/svp64: support mr/mrr modes

ppc/svp64: support ff/pr modes

ppc/svp64: support zz/dz/sz specifier

ppc/svp64: support sat specifier

ppc/svp64: support sea specifier

ppc/svp64: support els specifier

ppc/svp64: support w/dw/sw modes

ppc/svp64: support vec2/vec3/vec4 modes

ppc/svp64: support m/dm/sm modes

ppc/svp64: introduce svp64_decode stub

ppc/svp64: setup SVP64 opcodes table

opcodes: introduce SVP64 sources

opcodes: introduce SVP64 headers

ppc/svp64: introduce svp64_assemble stub

ppc: share pd_reg definition via libopcodes

ppc/svp64: support shadd/shadduw instructions

ppc/svp64: support divmod2du instruction

ppc/svp64: support maddedu instruction

ppc/svp64: support fptrans instructions

ppc/svp64: support bmask instruction

ppc/svp64: support absd instructions

ppc/svp64: support cprop instructions

ppc/svp64: support avgadd instructions

ppc/svp64: support fishmv instruction

ppc/svp64: support fmvis instruction

ppc/svp64: support svshape2 instruction

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/remap/#svshape
https://libre-soc.org/openpower/sv/remap/#svshape2
https://libre-soc.org/openpower/isa/simplev/

ppc: decouple SFFS and SVP64 extensions

[readline] Fix double free in _rl_scxt_dispose

Consider the following scenario.  We start gdb in TUI mode:
...
$ gdb -q -tui
...
and type ^R which gives us the reverse-isearch prompt in the cmd window:
...
(reverse-i-search)`':
...
and then type "foo", right-arrow-key, and ^C.

In TUI mode, gdb uses a custom rl_getc_function tui_getc.

When pressing the right-arrow-key, tui_getc:
- attempts to scroll the TUI src window, without any effect, and
- returns 0.

The intention of returning 0 is mentioned here in tui_dispatch_ctrl_char:
...
  /* We intercepted the control character, so return 0 (which readline
     will interpret as a no-op).  */
  return 0;
...

However, after this 0 is returned by the rl_read_key () call in
_rl_search_getchar, _rl_read_mbstring is called, which incorrectly interprets
0 as the first part of an utf-8 multibyte char, and tries to read the next
char.

In this state, the ^C takes effect and we run into a double free because
_rl_isearch_cleanup is called twice.

Both these issues need fixing independently, though after fixing the first we
no longer trigger the second.

The first issue is caused by the subtle difference between:
- a char array containing 0 chars, which is zero-terminated, and
- a char array containing 1 char, which is zero.

In mbrtowc terms, this is the difference between:
...
  mbrtowc (&wc, "", 0, &ps);
...
which returns -2, and:
...
  mbrtowc (&wc, "", 1, &ps);
...
which returns 0.

Note that _rl_read_mbstring calls _rl_get_char_len without passing it an
explicit length parameter, and consequently it cannot distinguish between the
two, and defaults to the "0 chars" choice.

Note that the same problem doesn't exist in _rl_read_mbchar.

Fix this by defaulting to the "1 char" choice in _rl_get_char_len:
...
-  if (_rl_utf8locale && l > 0 && UTF8_SINGLEBYTE(*src))
+  if (_rl_utf8locale && l >= 0 && UTF8_SINGLEBYTE(*src))
...

The second problem happens when the call to _rl_search_getchar in
_rl_isearch_callback returns.  At that point _rl_isearch_cleanup has already
been called from the signal handler, but we proceed regardless, using a cxt
pointer that has been freed.

Fix this by checking for "RL_ISSTATE (RL_STATE_ISEARCH)" after the call to
_rl_search_getchar:
...
   c = _rl_search_getchar (cxt);
+  if (!RL_ISSTATE (RL_STATE_ISEARCH))
+    return 1;
...

Tested on x86_64-linux.

Approved-By: Chet Ramey <chet.ramey@case.edu>
PR tui/30056
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30056

Automatic date update in version.in

[PR ld/22263][PR ld/25694] RISC-V: Avoid dynamic TLS relocs in PIE.

Lots of targets already fixed the TEXTREL problem for TLS in PIE.

* For PR ld/25694,
In the check_reloc, refer to spare and loongarch, they don't need to reserve
any local dynamic reloc for TLS LE in pie/pde, and similar to other targets.
So it seems like riscv was too conservative to estimate the TLS LE before.
Just break and don't goto static_reloc for TLS LE in pie/pde can fix the
TEXTREL problem.

* For PR ld/22263,
The risc-v code for TLS GD/IE in the relocate_section seems same as MIPS port.
So similar to MIPS, pr22570, commits 9143e72c6d4d and 1cb83cac9a89, it seems
also the right way to do the same thing for risc-v.

On risc-v, fixes
FAIL: Build pr22263-1

RISC-V haven't supported the TLS transitions, so will need the same fix (use
bfd_link_dll) in the future.

bfd/
PR ld/22263
PR ld/25694
* elfnn-riscv.c (riscv_elf_check_relocs): Replace bfd_link_pic with
bfd_link_dll for TLS IE.  Don't need to reserve the local dynamic
relocation for TLS LE in pie/pde, and report error in pic just like
before.
(riscv_elf_relocate_section): For TLS GD/IE, use bfd_link_dll rather
than !bfd_link_pic in determining the dynamic symbol index.  Avoid
the index of -1.

Automatic date update in version.in

Enhance objdump's --private option so that it can display the contents of PE format files.

  * od-pe.c: New file: Dumps fields in PE format headers.
  * configure.ac (od_vectors): Add objdump_private_desc_pe for PE format targets. (od_files): Add od-pe for PE format targets.
  * configure: Regenerate.
  * Makefile.am (CFILES): Add od-pe.c (EXTRA_objdump_SOURCE): Likewise.
  * Makefile.in: Generate.
  * NEWS: Mention the new feature.
  * doc/binutils.texi: Document the new support.
  * objdump.c (wide_output): Change from local to global.
  * objdump.h (wide_output): Prototype. (objdump_private_desc_pe): Prototype.
  * testsuite/binutils-all/objdump.exp: Add a test of the new feature.

Remove duplicate definition

* coff/pe.h (IMAGE_FILE_MACHINE_AMD64): Remove duplicate
definition.  Alphabetize.

x86: fix disassembler build after 1a3b4f90bc5f

In commit 1a3b4f90bc5f ("x86: convert two pointers to (indexing)
integers") I neglected the fact that compilers may warn about comparing
ptrdiff_t (signed long) with size_t (unsigned long) values. Since just
before we've checked that the value is positive, simply add a cast
(despite my dislike for casts).

[gdb/testsuite] Add test-case gdb.tui/color-prompt.exp

Add a test-case that sets a prompt with color in TUI.

The line containing the prompt is shown by get_line_with_attrs as follows:
...
<fg:31>(gdb) <fg:default>
...

The 31 means red, but only for foreground colors, for background colors 41
means red.

Make this more readable by using color names for both foreground and
background, such that we have instead:
....
<fg:red>(gdb) <fg:default>
...

Tested on x86_64-linux.

[gdb/testsuite] Add invisible and blinking attributes in tuiterm

I noticed curses using the invisible and blinking attributes.

Add these in tuiterm.

Tested on x86_64-linux.

[gdb/testsuite] Fix reverse attribute in tuiterm

I noticed in proc Term::_csi_m arguments that while parameters 7 and 27 are
supposed to set the reverse attribute to 1 and 0, in fact it's set to 1 in
both cases:
...
      7 {
set _attrs(reverse) 1
    }
  ...
    27 {
set _attrs(reverse) 1
      }
...

Fix this and add a regression test in gdb.tui/tuiterm.exp.

Tested on x86_64-linux.

iamcu: suppress tests which can't possibly work

With neither --32 nor --64 passed to gas, advanced features like AVX
aren't available without explicitly enabling them.

x86-64: improve gas diagnostic when no 32-bit target is configured

Make this similar to --64 and --x32: Check whether a suitable target
exists.

x86-64: conditionalize tests using --32

Using this option doesn't really work when no support for any 32-bit
target was configured in (as is the case for at least cloudabi and
rdos).

x86: split gas testsuite .exp file

The set of 32-bit-only and 64-bit-only tests has grown quite large. In
particular when one's after only the results for the 64-bit set, having
them live in a separate .exp file is easier / faster.

x86: convert two pointers to (indexing) integers

This in particular reduces the number of pointers to non-const that we
have (and that could potentially be used for undue modification of
state). As a result, fetch_code()'s 2nd parameter can then also become
pointer-to-const.

x86: disassembling over-long insns

The present way of dealing with them - misusing MAX_MNEM_SIZE, which has
nothing to do with insn length - leads to inconsistent results. Since we
allow for up to MAX_CODE_LENGTH - 1 prefix bytes (which then could be
followed by another MAX_CODE_LENGTH "normal" insn bytes until we're done
decoding), size the_buffer[] accordingly.

Move struct dis_private down to be able to use MAX_CODE_LENGTH without
moving its #define. While doing this also alter the order to have the
potentially large array last.

x86: use fixed-width type for codep and friends

This first of all removes a dependency on bfd_byte and unsigned char
being the same types. It further eliminates the need to mask by 0xff
when fetching values (which wasn't done fully consistently anyway),
improving code legibility.

While there, where possible add const.

x86: figure braces aren't really part of mnemonics

Instead they're separators for pseudo-prefixes. Don't insert them in
mnemonic_chars[], handling them explicitly in parse_insn() instead. Note
that this eliminates the need for another separator after a pseudo-
prefix. While maybe not overly interesting for a following real
mnemonic, I view this as quite desirable between multiple successive
pseudo-prefixes (bringing things in line with the other use of figure
braces in AVX512's zeroing-masking).

Drop the unused is_mnemonic_char() at this occasion.

x86: de-duplicate operand_special_chars[] wrt extra_symbol_chars[]

Having to add characters to both arrays can easily lead to oversights.
Consuming extra_symbol_chars[] when populating operand_chars[] also
allows to drop two special cases in md_begin().

Constify operand_special_chars[] at this occasion.

sframe/doc: minor improvements for readability

libsframe/
* sframe-spec.texi: Cosmetic fixes.

libsframe: revisit sframe_find_fre API

Inspite of implementing a rather simple functionality, this function was
relatively difficult to follow, and maintain.  Some changes are done now
to address that - refactor the function and use better names to make it
more readable.

The changes to the implementation do not cause any change in the
contract of the API.

libsframe/
        * sframe.c (sframe_fre_get_end_ip_offset): to here...
        (sframe_find_fre): Refactor some bits from...

libsframe: use const char * consistently for immutable FRE buffers

libsframe/
        * sframe.c (sframe_decode_fre): Use const char * datatype when
handling buffer containing the FREs.
(sframe_fre_get_end_ip_offset): Likewise.
(sframe_find_fre): Likewise.
(sframe_decoder_get_fre): Likewise.

libsframe: use uint8_t data type for FRE info related stubs

libsframe/
* sframe.c: Use uint8_t for FRE offset count and FRE offset
size.  Use uint8_t for FRE info word as well.

PR22263 ld test

A number of targets that I test regularly fail the "Build pr22263-1"
test for various reasons.

arm-linux-gnueabi: "undefined reference to `__aeabi_read_tp'"
ia64-linux-gnu: "Explicit stops are ignored in auto mode"
m68k-linux-gnu: "undefined reference to `__m68k_read_tp'"
microblaze-linux-gnu: "undefined reference to `__tls_get_addr'"
nios2-linux-gnu, s390-linux-gnu and sh4-linux-gnu have a tprel reloc in .got
riscv64-linux-gnu has a dynamic relocation in text

So only riscv really fails the pr.  The rest fail due to test issues
or lack of a linker optimisation.  Lack of an optimisation isn't
really a fail, but it's worth keeping the test to ensure those
optimisations don't regress.  The xfail targets may not be an
exhaustive list.  This just tidies test results for those for which I
have cross compilers installed.

PR 22263
* testsuite/ld-elf/tls.exp: Split pr22263 test into two parts,
one to check for -z text errors, the other to check tprel
linker optimisation.  Supply needed symbols and assembler flags.
xfail the linker optimisation on targets known to fail.

Make MI commands const-correct

I've had this patch for a while now and figured I'd update it and send
it.  It changes MI commands to use a "const char * const" for their
argv parameter.

Regression tested on x86-64 Fedora 36.

Acked-By: Simon Marchi <simon.marchi@efficios.com>

Automatic date update in version.in

Fix scoped_value_mark not working with empty value chain

The scoped_value_mark helper class was setting its internal
mark value to NULL to indicate that the value chain had already
been freed to mark.

However, value_mark() also returns NULL if the value chain is
empty at the time of call.

This lead to the situation that if the value chain was empty
at the time the scoped_value_mark was created, the class
would not correctly clean up the state when it was destroyed,
because it believed it had already been freed.

I noticed this because I was setting a watchpoint very early
in my debug session, and it was becoming a software watchpoint
rather than hardware. Running any command that called evaluate()
beforehand (such as 'x 0') would mean that a hardware watchpoint
was correctly used. After some careful examination of the
differences in execution, I noticed that values were being freed
later in the 'bad case', which lead me to notice the issue with
scoped_value_mark.

gdb: remove breakpoint_pointer_iterator

Remove the breakpoint_pointer_iterator layer.  Adjust all users of
all_breakpoints and all_tracepoints to use references instead of
pointers.

Change-Id: I376826f812117cee1e6b199c384a10376973af5d
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: make filtered_iterator::operator* return the same thing as underlying iterator

This is the same idea as the previous patch, but for filtered_iterator.
Without this patch, I would see this when applying the patch that
removes reference_to_pointer_iterator from breakpoint_range:

      CXX    breakpoint.o
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void download_tracepoint_locations()’:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:11007:41: error: cannot allocate an object of abstract type ‘breakpoint’
    11007 |   for (breakpoint &b : all_tracepoints ())
          |                                         ^
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
      619 | struct breakpoint : public intrusive_list_node<breakpoint>
          |        ^~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
      250 | breakpoint::~breakpoint ()
          | ^~~~~~~~~~

Change-Id: I05285ff27d21cb0ab80cba392ec4e959167e3cd7
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: make basic_safe_iterator::operator* return the same thing as underlying iterator

Using the following patch that removes the reference_to_pointer_iterator
from breakpoint_range, I would get:

      CXX    breakpoint.o
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’
     3030 |   for (breakpoint &b : all_breakpoints_safe ())
          |                                              ^
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
                     from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note:   because the following virtual functions are pure within ‘breakpoint’:
      619 | struct breakpoint : public intrusive_list_node<breakpoint>
          |        ^~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note:     ‘virtual breakpoint::~breakpoint()’
      250 | breakpoint::~breakpoint ()
          | ^~~~~~~~~~

This is because the operator* method of the basic_safe_iterator iterator
wrapper returns a value_type.  So, even if the method of the underlying
iterator (breakpoint_iterator, an intrusive_list iterator) returns a
`breakpoint &`, the method of the wrapper returns a `breakpoint`.

I think it would make sense for iterator wrappers such as
basic_safe_iterator to return the exact same thing as the iterator they
wrap.  At least, it fixes my problem.

Change-Id: Ibbcd390ac03d2fb6ae4854923750c8d7c3c04e8a
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb: link breakpoints with intrusive_list

Change-Id: I043d8d6f3dd864d80d5088f6ffc2c098337249ea
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb: remove bp_location_pointer_iterator

Remove the bp_location_pointer_iterator layer.  Adjust all users of
breakpoint::locations to use references instead of pointers.

Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb: use intrusive_list for breakpoint locations

Replace the hand-maintained linked lists of breakpoint locations with
and intrusive list.

 - Remove breakpoint::loc, add breakpoint::m_locations.

 - Add methods for the various manipulations that need to be done on the
   location list, while maintaining reasonably good encapsulation.

 - bp_location currently has a default constructor because of one use
   in hoist_existing_locations.  hoist_existing_locations now returns a
   bp_location_list, and doesn't need the default-constructor
   bp_location anymore, so remove the bp_location default constructor.

 - I needed to add a call to clear_locations in delete_breakpoint to
   avoid a use-after-free.

 - Add a breakpoint::last_loc method, for use in
   set_breakpoint_condition.

bp_location_range uses reference_to_pointer_iterator, so that all
existing callers of breakpoint::locations don't need to change right
now.  It will be removed in the next patch.

The rest of the changes are to adapt the call sites to use the new
methods, of breakpoint::locations, rather than breakpoint::loc directly.

Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: add missing increment/decrement operators to reference_to_pointer_iterator

Using the following patch, I would get this build failure:

      CXX    breakpoint.o
    In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66,
                     from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36,
                     from /usr/include/c++/13.1.1/bits/hashtable.h:35,
                     from /usr/include/c++/13.1.1/bits/unordered_map.h:33,
                     from /usr/include/c++/13.1.1/unordered_map:41,
                     from /usr/include/c++/13.1.1/functional:63,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206,
                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:26,
                     from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20:
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’:
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21:   required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19:   required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’
    /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19:   required from here
    /usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’)
      179 |           --__i;
          |           ^~~~~

This points out that while intrusive_list_iterator has an operator--,
the reference_to_pointer_iterator wrapper does not.  I'm not to sure why
the compiler chooses the overload of __advance that accepts a
_BidirectionalIterator, given that reference_to_pointer_iterator can't
be decremented, but adding those operators seems like the right thing to
do in any case, for completeness.

Change-Id: I8e2044b6734fadf0f21093047cf35bb7080dbdc3
Reviewed-By: Andrew Burgess <aburgess@redhat.com>