aboutsummaryrefslogtreecommitdiff
path: root/opcodes
AgeCommit message (Collapse)AuthorFilesLines
2023-03-16cpu/mem.opc whitespace tidyAlan Modra2-24/+23
cpu/ * mep.opc: Whitespace and formatting. opcodes/ * mep-asm.c: Regenerate. * mep-dis.c: Regenerate.
2023-03-15Fix an illegal memory access when disassembling a corrupt MeP file.Nick Clifton2-0/+19
PR 30231 * mep.opc (mep_print_insn): Check for an out of range index.
2023-03-15Fix an illegal memory access when disassebling a corrupt ARM file.Nick Clifton2-5/+17
PR 30230 * arm-dis.c (get_sym_code_type): Check for non-ELF symbols.
2023-02-28[Aarch64] Add Binutils support for MECRichard Ball2-0/+13
This change supports MEC which is part of RME (Realm Management Extension).
2023-02-27Updated Serbian translations for gold, gprof and opcodes sub-directoriesNick Clifton1-300/+301
2023-02-25opcodes/m68k: enable libopcodes styling for GDBAndrew Burgess1-0/+5
The following commit added libopcodes styling for m68k: commit c22ff449275c91e4842bb10c650e83c572580f65 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.
2023-02-24x86: MONITOR/MWAIT are not SSE3 insnsJan Beulich5-7148/+7161
These have their own CPUID bit and hence they should also have their own separate control.
2023-02-24x86-64: don't permit LAHF/SAHF with "generic64"Jan Beulich5-5127/+5166
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.
2023-02-24x86: have insns acting on segment selector values allow for consistent operandsJan Beulich2-897/+964
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.
2023-02-24x86: restrict insn templates accepting negative 8-bit immediatesJan Beulich2-154/+154
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.
2023-02-22x86-64: LAR and LSL don't need REX.WJan Beulich2-8/+8
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.
2023-02-22x86: optimize BT{,C,R,S} $imm,%regJan Beulich2-8/+8
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.
2023-02-20opcodes: style m68k disassembler outputAndreas Schwab1-116/+238
2023-02-14x86: {LD,ST}TILECFG use an extension opcodeJan Beulich2-4/+4
It being zero and happening to work right now doesn't mean the insns shouldn't be spelled out properly.
2023-02-13PR30120: fix x87 fucomp misassembledMichael Matz2-2/+2
this fixes the entry for 'fucomp' to use the correct Reg value (otherwise it's assembled as 'fucom').
2023-02-13opcodes/mips: disassemble unknown micromips instructions as two shortsAndrew Burgess1-5/+8
Before commit: commit 2438b771ee07be19d5b01ea55e077dd8b7cef445 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.
2023-02-10x86: drop use of VEX3SOURCESJan Beulich4-7676/+3850
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.
2023-02-10x86: drop use of XOP2SOURCESJan Beulich3-29/+27
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.
2023-02-10x86: limit use of XOP2SOURCESJan Beulich2-5/+5
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).
2023-02-10x86: move (and rename) opcodespace attributeJan Beulich3-10991/+11023
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.
2023-02-03bpf: fix error conversion from long unsigned int to unsigned int ↵Guillermo E. Martinez2-26/+30
[-Werror=overflow] 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.
2023-02-03RISC-V: don't disassemble unrecognized insns as .byteJan Beulich1-30/+20
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.
2023-01-31RISC-V: make C-extension JAL available again for (32-bit) assemblyJan Beulich1-1/+1
Along with the normal JAL alias, the C-extension one should have been moved as well by 839189bc932e ("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.
2023-01-27x86: use ModR/M for FPU insns with operandsJan Beulich3-216/+216
This is the correct way of expressing things; encoding the ModR/M byte directly in base_opcode has always been bogus.
2023-01-27opcodes: suppress internationalization on build helper toolsJan Beulich3-47/+2
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.
2023-01-27x86: remove internationalization from i386-gen.cJan Beulich1-26/+23
This is a build time helper utility, which doesn't require translation.
2023-01-20x86: split i386-gen's opcode hash entry structJan Beulich1-23/+28
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().
2023-01-20x86: embed register and alike names in disassemblerJan Beulich1-34/+34
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().
2023-01-20x86: embed register names in reg_entryJan Beulich1-1/+1
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.
2023-01-20x86: absorb allocation in i386-genJan Beulich1-2/+5
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.
2023-01-20x86: re-use insn mnemonic strings as much as possibleJan Beulich3-4534/+4216
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%.
2023-01-20x86: move insn mnemonics to a separate tableJan Beulich6-3835/+8549
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).
2023-01-03opcodes: xtensa: fix jump visualization for FLIXMax Filippov1-3/+20
opcodes/ * xtensa-dis.c (print_insn_xtensa): Add local variables insn_type, target and imm_pcrel to track control flow across multiple slots.
2023-01-03opcodes: xtensa: implement styled disassemblyMax Filippov1-11/+22
opcodes/ * xtensa-dis.c (print_xtensa_operand) (print_insn_xtensa): Replace fprintf_func with fprintf_styled_func.
2023-01-03Updated translations for various languages and sub-directoriesNick Clifton4-1544/+1453
2023-01-01Update year range in copyright notice of binutils filesAlan Modra274-278/+278
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.
2022-12-31Update version number and regenerate filesNick Clifton2-254/+264
2022-12-31Add markers for 2.40 branchNick Clifton1-0/+4
2022-12-22x86: correct/improve TSX controlsJan Beulich2-1/+32
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.
2022-12-22x86: add dependencies on SVMEJan Beulich2-7/+49
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).
2022-12-22x86: add dependencies on VMXJan Beulich2-2/+33
Both EPT and VMFUNC are extensions to VMX.
2022-12-22x86: correct XSAVE* dependenciesJan Beulich2-8/+10
Like various other features AMX-TILE takes XSAVE as a prereq. XSAVES, unconditionally using compacted format, in turn effectively takes XSAVEC as a prereq (an SDM clarification to this effect is in the works).
2022-12-22x86: correct dependencies of a few AVX512 sub-featuresJan Beulich2-10/+10
Like AVX512-FP16, several other extensions require wider than 16-bit mask registers. As a result they take AVX512BW as a prereq, not (just) AVX512F. Which in turn points out wrong expectations in the noavx512-1 testcase.
2022-12-22x86: add dependencies on AVX2Jan Beulich2-9/+31
Like AVX-VNNI both VAES and VPCLMUL take AVX2 as a prereq, for operating on up to 256-bit packed integer vectors.
2022-12-22x86: correct SSE dependenciesJan Beulich2-48/+92
SSE itself takes FXSR as a prereq. Like AES, PCLMUL, and SHA both GFNI and KL take SSE2 as a prereq, for operating on packed integers. And while correcting KL also record it as a prereq to WIDEKL.
2022-12-22x86: re-work ISA extension dependency handlingJan Beulich2-997/+883
Getting both forward and reverse ISA dependencies right / consistent has been a permanent source of mistakes. Reduce what needs specifying manually to just the direct forward dependencies. Transitive forward dependencies as well as reverse ones are now derived and hence cannot go out of sync anymore (at least in the vast majority of cases; there are a few special cases to still take care of manually). In the course of this several CPU_ANY_*_FLAGS disappear, requiring adjustment to the assembler's cpu_arch[]. Note that to retain the correct reverse dependency of AVX512F wrt AVX512-VP2INTERSECT, the latter has the previously missing AVX512F prereq added. Note further that to avoid adding the following undue prereqs: * ATHLON, K8, and AMDFAM10 gain CMOV and FXSR, * IAMCU gains 387, auxiliary table entries (including a colon-separated modifier) are introduced in addition to the ones representing from converting the old table. To maintain forward-only dependencies between AVX (XOP) and SSE* (SSE4a) (i.e. "nosse" not disabling AVX), reverse dependency tracking is artifically suppressed. As a side effect disabling of SSE or SSE2 will now also disable AES, PCLMUL, and SHA (respective elements were missing from CPU_ANY_SSE2_FLAGS).
2022-12-21x86: rename CheckRegSize to CheckOperandSizeJan Beulich3-511/+511
While originally indeed used for register size checking only, the attribute has been used for memory operand size checking as well already for quite a while, with more such uses recently having been added.
2022-12-20Re: x86: remove i386-opc.cAlan Modra1-1/+0
Regen opcodes/po/POTFILES.in
2022-12-19x86: omit Cpu prefixes from opcode tableJan Beulich2-2220/+2238
These enumerators can be used in only one specific field, and hence the Cpu prefix isn't needed ther for disambiguation / name space separation.
2022-12-16x86: change representation of extension opcodeJan Beulich3-2286/+2288
Having a "None" field in the vast majority of entries is needlessly cluttering the overall table. Instead of this being a separate field, use a representation matching that of Intel SDM and AMD PM for the main use of the field: Append the value after a / as the separator.