PR 30231
  * mep.opc (mep_print_insn): Check for an out of range index.

  PR 30230
  * arm-dis.c (get_sym_code_type): Check for non-ELF symbols.

This change supports MEC which is part of RME (Realm Management Extension).

The following commit added libopcodes styling for m68k:

  commit c22ff449
  Date:   Tue Feb 14 18:07:19 2023 +0100

      opcodes: style m68k disassembler output

but didn't set disassemble_info::created_styled_output in
disassemble.c, which is needed in order for GDB to start using the
libopcodes based styling.

This commit fixes this small oversight.  GDB now styles correctly.

These have their own CPUID bit and hence they should also have their own
separate control.

The feature isn't universally available on 64-bit CPUs.

Note that in i386-gen.c:isa_dependencies[] I'm only adding it to models
where I'm certain the functionality exists. For Nocona and Core I'm
uncertain in particular.

While MOV to/from segment register as well as selector storing insns
already permit 32- and 64-bit GPR operands, selector loading insns and
ARPL do not. Split templates accordingly.

For shifts (but not ordinary rotates) and other cases where an immediate
describes e.g. a bit count or position, allowing negative operands is at
best confusing. An extreme example would be the two rotate-through-carry
insns, where a negative value would _not_ mean rotating the
corresponding number of bits in the other direction. To refuse such,
give meaning to the combination of Imm8 and Imm8S in templates (so far
these weren't used together anywhere). The issue was with
smallest_imm_type() blindly setting .imm8 for signed numbers determined
to fit in a byte.

VPROT{B,W,D,Q} is a little special: The rotate count there is a signed
quantity, so Imm8 is replaced by Imm8S. Adjust affected testcases
accordingly as well.

Another small adjustment to the testsuite is necessary: AAM and AAD were
never sensible to use with 0xffffff90 operands. This should have been an
error.

Just like we suppress emitting REX.W for e.g. MOV from/to segment
register, there's also no need for it for LAR and LSL - these can only
ever return 32-bit values and hence always zero-extend their results
anyway.

While there also drop the redundant Word from the first operand of
the second template each - this is already implied by Reg16.

In 64-bit mode BT can have REX.W or a data size prefix dropped in
certain cases. Outside of 64-bit mode all 4 insns can have the data
size prefix dropped in certain cases.

It being zero and happening to work right now doesn't mean the insns
shouldn't be spelled out properly.

this fixes the entry for 'fucomp' to use the correct Reg value
(otherwise it's assembled as 'fucom').

Before commit:

  commit 2438b771
  Date:   Wed Nov 2 15:53:43 2022 +0000

      opcodes/mips: use .word/.short for undefined instructions

unknown 32-bit microMIPS instructions were disassembled as a raw
32-bit number with no '.word' directive.  The above commit changed
this and added a '.word' directive before the 32-bit number.

It was pointed out on the mailing list, that for microMIPS it would be
better to display such 32-bit instructions using a '.short' directive
followed by two 16-bit values.

This commit updates the mips disassembler to do this, and adds a new
test that validates this output.

The attribute really specifies that the sum of register and memory
operands is 4. Express it like that in most places, while using the 2nd
(apart from XOP) CPU feature flags (FMA4) in reversed operand matching
logic.

With the use in build_modrm_byte() gone, part of an assertion there
also becomes meaningless - simplify that at the same time.

With all uses of the opcode modifier field gone, also drop that.

The few XOP insns which used it wrongly didn't have VexVVVV specified.
With that added, the only further missing piece to use more generic code
elsewhere is SwapSources - see e.g. the BMI2 insns for similar operand
patterns.

With the only users gone, drop the #define as well as the special case
code.

The VPROT* forms with an immediate operand are entirely standard in the
way their ModR/M bytes are built. There's no reason to invoke special
case code. With that the handling of an immediate there can also be
dropped; it was partially bogus anyway, as in its "no memory operands"
portion it ignores the possibility of an immediate operand (which was
okay only because that case was already handled by more generic code).

This really isn't a "modifier" and rather ought to live next to the base
opcode anyway. Use the bits we presently have available to fit in the
field, renaming it to opcode_space. As an intended side effect this
helps readability at the use sites, by shortening the references quite a
bit.

In generated code arrange for human readable output, by using the
SPACE_* constants there rather than raw numbers. This may aid debugging
down the road.

Regenerating BPF target using the maintainer mode emits:
.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
  57 |   64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }

The use of a narrow size to handle the mask CGEN in instruction format
is causing this error.  Additionally eBPF `call' instructions
constructed by expressions using symbols (BPF_PSEUDO_CALL) emits
annotations in `src' field of the instruction, used to identify BPF
target endianness.

cpu/
	* bpf.cpu (define-call-insn): Remove `src' field from
	instruction mask.

include/
	*opcode/cge.h (CGEN_IFMT): Adjust mask bit width.

opcodes/
	* bpf-opc.c: Regenerate.

Insn width granularity being 16 bits, producing byte granular output
isn't very useful. With there being a way to specific otherwise
unknown insns to the assembler, use that same representation (to be
precise: its <length>,<encoding> flavor) for disassembly.

Along with the normal JAL alias, the C-extension one should have been
moved as well by 839189bc ("RISC-V: re-arrange opcode table for
consistent alias handling"), for the assembler to actually be able to
use it where/when possible.

Since neither this nor any other compressed branch insn was being tested
so far, take the opportunity and introduce a new testcase covering those.

This is the correct way of expressing things; encoding the ModR/M byte
directly in base_opcode has always been bogus.

While one of the two actually having been instrumented (i386-gen.c) now
has that instrumentation dropped, there's still no point in honoring
such instrumentation in general (i.e. now for ia64-gen.c only), as that
only leads to a waste of resources.

With CFILES then being merely an alias of LIBOPCODES_CFILES, drop the
former variable altogether.

This is a build time helper utility, which doesn't require translation.

All glibc malloc() implementations I've checked have a smallest
allocation size worth of 3 pointers, with an increment worth of 2
pointers. Hence mnemonics with multiple templates can be stored more
efficiently when maintaining the shared "name" field only in the actual
hash entry. (To express the shared nature, also convert "name" to by
pointer-to-const.)

While doing the conversation also pull out common code from the involved
if/else construct in expand_templates().

Register names are (including their nul terminators) on average almost 4
bytes long. Otoh no register name is longer than 8 bytes. Hence even for
32-bit builds using a pointer is only slightly more space efficient than
embedding the strings. A level of indirection can be also avoided by
embedding the names as an array of 8 characters directly in the arrays,
and the number of base relocations in libopcodes.so (or PIE builds of
statically linked executables) goes down as well.

To amortize for the otherwise reduced folding of string literals by the
linker, use att_names_seg[] in place of string literals in append_seg()
and OP_ESreg().

Register names are (including their nul terminators) on average almost 4
bytes long. Otoh no register name is longer than 7 bytes. Hence even for
32-bit builds using a pointer is only slightly more space efficient than
embedding the strings. A level of indirection can be also avoided by
embedding the names as an array of 8 characters directly in the struct,
and the number of base relocations in PIE builds of gas goes down as
well.

When generating the mnemonic string table we already set up an
identifier for the following entry in a number of cases. Re-use that on
the next loop iteration rather than re-doing allocation and conversion.

Compact the mnemonic string table such that the tails of longer
mnemonics are re-used for shorter ones, going beyond what compilers
would typically do, but matching what ELF linkers may do when processing
SHF_MERGE|SHF_STRINGS sections. This reduces table size by about 12.5%.

Using full pointers to reference the insn mnemonic strings is not very
efficient. With overall string size presently just slightly over 20k,
even a 16-bit value would suffice. Use "unsigned int" for now, as
there's no good use we could presently make of the otherwise saved 16
bits.

For 64-bit builds this reduces table size by 6.25% (prior to the recent
ISA extension additions it would have been 12.5%), with a similar effect
on cache occupation of table entries accessed. For PIE builds of gas
this also reduces the number of base relocations quite a bit (obviously
independent of bitness).

opcodes/
	* xtensa-dis.c (print_insn_xtensa): Add local variables
	insn_type, target and imm_pcrel to track control flow across
	multiple slots.

opcodes/
	* xtensa-dis.c (print_xtensa_operand)
	(print_insn_xtensa): Replace fprintf_func with
	fprintf_styled_func.

The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.

TSXLDTRK takes RTM as a prereq. Additionally introduce an umbrella "tsx"
extension option covering both RTM and HLE, paralleling the "abm" one we
already have.

SEV-ES is an extension to SVME. SNP in turn is an extension to SEV-ES,
and yet in turn RMPQUERY is a SNP extension.

Note that cpu_arch[] has no SNP entry, so CPU_ANY_SNP_FLAGS remains
unused (just like CPU_SNP_FLAGS already is).

Both EPT and VMFUNC are extensions to VMX.