aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-04sim: don't hardcode -ldl for SDL supportMike Frysinger4-11/+17
Since we use AC_SEARCH_LIBS to find dlopen, we don't need to hardcode -ldl when using SDL ourselves.
2022-11-04Support Intel AVX-NE-CONVERTkonglin116-4169/+5420
gas/ChangeLog: * NEWS: Support Intel AVX-NE-CONVERT. * config/tc-i386.c: Add avx_ne_convert. * doc/c-i386.texi: Document .avx_ne_convert. * testsuite/gas/i386/i386.exp: Run AVX NE CONVERT tests. * testsuite/gas/i386/avx-ne-convert-intel.d: New test. * testsuite/gas/i386/avx-ne-convert.d: Ditto. * testsuite/gas/i386/avx-ne-convert.s: Ditto. * testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto. * testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto. opcodes/ChangeLog: * i386-dis.c (Mw): New. (PREFIX_VEX_0F3872): Ditto. (PREFIX_VEX_0F38B0_W_0): Ditto. (PREFIX_VEX_0F38B1_W_0): Ditto. (VEX_W_0F3872_P_1): Ditto. (VEX_W_0F38B0): Ditto. (VEX_W_0F38B1): Ditto. (prefix_table): Add PREFIX_VEX_0F3872, PREFIX_VEX_0F38B0_W_0, PREFIX_VEX_0F38B1_W_0. (vex_w_table): Add VEX_W_0F3872_P_1, VEX_W_0F38B0, VEX_W_0F38B1. * i386-gen.c (cpu_flag_init): Add CPU_AVX_NE_CONVERT_FLGAS and CPU_ANY_AVX_NE_CONVERT_FLAGS. (cpu_flags): Add CpuAVX_NE_CONVERT. * i386-init.h: Regenerated. * i386-opc.h (CpuAVX_NE CONVERT): New. (i386_cpu_flags): Add cpuavx_ne_convert. * i386-opc.tbl: Add Intel AVX-NE-CONVERT instructions. * i386-tbl.h: Regenerated.
2022-11-04i386: Rename <xy> template.konglin11-17/+18
opcodes/ * i386-opc.tbl: Rename <xy> template for VEX insn with x/y suffix to <Vxy>. Rename <xy> for EVEX insn with x/y suffix to <Exy>.
2022-11-04Support multiple .eh_frame sectionsJojo R6-3/+49
This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE, it allows backend to enable this feature and use '--gc-sections' simply. * gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New. (MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. * gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. (is_now_linkonce_segment): Likewise. (get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section. * bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New. * bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise. * bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for elf_backend_can_make_multiple_eh_frame.
2022-11-04gas/doc/internals.texi: fix typoJojo R1-2/+1
* gas/doc/internals.texi (md_emit_single_noop_insn): fix '@var missing closing brace' * gas/doc/internals.texi (Hash tables): fix '@menu reference to nonexistent node `Hash tables''
2022-11-04sim: drop -lm from SIM_EXTRA_LIBSMike Frysinger7-9/+2
We have configure tests for this in the top-level configure script to link this when necessary, so we don't need to explicitly list it for specific ports.
2022-11-04sim: build: change AC_CHECK_LIB to AC_SEARCH_LIBSMike Frysinger3-107/+150
With more C libraries moving functions entirely into the main -lc, change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there first and avoid extra linkage when possible.
2022-11-04sim: build: drop duplicate $(LIBS) usageMike Frysinger1-2/+1
COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus @LIBS@. This leds to the values being used twice. Inline the CONFIG_LIBS variable without @LIBS@ since it's used only once.
2022-11-04sim: build: switch to bfd & opcodes libtool linker scriptsMike Frysinger9-431/+18
Now that we use libtool to link, we don't need to duplicate all the libs that bfd itself uses. This simplifies the configure & Makefile.
2022-11-04sim: build: switch to libtool for linkingMike Frysinger4-7/+19
The top-level already sets up a libtool script for the host, so use that when linking rather than invoking CC directly. This will also happen when we (someday) move the building to pure automake.
2022-11-04Automatic date update in version.inGDB Administrator1-1/+1
2022-11-04sim: testsuite: fix cris stat3 in diff setupsMike Frysinger1-6/+10
This test uses the test itself as an input to stating regular files. This gets funky though: when we run check in parallel, the output object dir is the subdir that matches the .exp file. When we run with -j1, the output object dir is the sim builddir itself. The old test would append argv[0] to find the file, while the new test uses basename on it. Each method works in only one of the aforementioned build scenarios. Rather than complicate this any more, switch to a different file that we know will always exist: the Makefile.
2022-11-04sim: testsuite: fix cris badarch in multi-target buildsMike Frysinger1-1/+1
This test assumes that /bin/sh will never be a CRIS ELF by way of assuming that the current bfd cannot load it (since a basic cris cross-compiler only understands CRIS ELFs). In a multi-target build though, bfd understands just about every ELF out there, so we're able to read the /bin/sh format before failing at a diff point in the cris code. Let's switch to using / instead since it'll fail for a similar reason (at least similar enough for what this test is testing).
2022-11-04sim: cleanup unused SIM_EXTRA_CFLAGSMike Frysinger3-7/+0
We want to eventually delete this, so at least drop the empty ones.
2022-11-04sim: m32c/rx: drop useless $(ENDLIST)Mike Frysinger2-10/+4
This is used to allow for dangling \ in object lists, but these are the only ports that do it, and it isn't really necessary. Punt it to keep the various makefiles harmonized.
2022-11-04sim: mips: simplify fpu configure logicMike Frysinger2-22/+14
The configure code always defaults to HARD_FLOATING_POINT, so inline that value and drop redundant target checks as a result.
2022-11-04sim: erc32: link sis to run programMike Frysinger1-6/+3
The erc32 sim does a lot itself, including handling of the CLI. It used to provide a run-compatible interface in the pre-nrun days, but it was dropped when the old run interface was punted. Since the old commit 465fb143c87076b6416a8d0d5dd79bb016060fe3 ("sim: make nrun the default run program"), the erc32 run & sis programs have been the same, and erc32 hasn't provide a real run-compatible interface. Simplify this by linking the two programs via ln/cp instead of running the linking phase twice to produce the same result. If/when we fix up the erc32 port to have a proper run interface, it should be easy to split these back apart into real programs. Note: the interf.o reference in here is a bit of a misdirect. Since that object is placed into libsim.a, it's never been linked into the programs since the linker ignores objects that aren't referenced, and only gdb uses those symbols.
2022-11-03V850 Linker: do not complain about RWX segments.Nick Clifton2-2/+9
PR 29748 * configure.tgt (ac_default_ld_warn_rwx_segments): Set to 0 for the V850.
2022-11-03sim: v850: switch to standard (high-level) trace definesMike Frysinger3-6/+2
The v850 port uses -DDEBUG to control whether to enable internal tracing. We already have such options via the common trace framework, and those can be controlled at build time via configure flags (which the v850 code currently cannot). So switch it over to WITH_TRACE_ANY_P to simplify the v850 build code even if it doesn't (yet) respect any other trace options.
2022-11-03sim: ppc: include copyright & license in --versionMike Frysinger1-0/+5
This makes it match the other sim run programs and GNU tools.
2022-11-03sim: update --version copyright yearMike Frysinger1-1/+1
Probably should have done this 11 months ago ...
2022-11-03sim: ppc: drop use of DATE & TIMEMike Frysinger1-6/+0
No other tool does this, sim or otherwise, and it makes the ppc build non-reproducible. Drop it to simplify & make reproducible.
2022-11-03gdb: Fix issue with Clang CLI macrosBruno Larsen10-11/+179
Clang up to version 15 (current) adds macros that were defined in the command line or by "other means", according to the Dwarf specification, after the last DW_MACRO_end_file, instead of before the first DW_MACRO_start_file, as the specification dictates. When GDB reads the macros after the last file is closed, the macros never end up "in scope" and so we can't print them. This has been submitted as a bug to Clang developers (https://github.com/llvm/llvm-project/issues/54506), and PR macros/29034 was opened for GDB to keep track of this. Seeing as there is no expected date for it to be fixed, add a workaround for all current versions of Clang. The workaround detects when the main file would be closed and if the producer is Clang, and turns that operation into a noop, so we keep a reference to the current_file as those macros are read. A test case was added to confirm the functionality, and the KFAIL for running gdb.base/macro-source-path when using clang. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29034 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-03AVR Linker: Allow the start of the data region to be specified on the linker ↵Nick Clifton1-1/+1
command line. [Fix PR number in ChangeLog entry] PR 29741 * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value has not been provided on the command line then use DATA_ORIGIN. (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
2022-11-03AVR Linker: Allow the start of the data region to specified on the command line.Nick Clifton2-1/+10
PR 29471 * scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define. If a value has not been provided on the command line then use DATA_ORIGIN. (MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.
2022-11-03sim: move common flags to default AM_CPPFLAGSMike Frysinger5-175/+39
Since all host files we compile use these settings, move them out of libcommon.a and into the default AM_CPPFLAGS. This has the effect of dropping the custom per-target automake rules. Currently it saves us ~150 lines, but since it's about ~8 lines per object, the overhead will increase quite a bit as we merge more files into a single build. This also changes the object output names, so we have to tweak the rules that were pulling in the common objects when linking.
2022-11-03sim: merge gnulib logic into the top-levelMike Frysinger4-3/+20
We aren't using this just yet, but we will, so make it available to building of common sim files.
2022-11-03sim: common: remove unused include pathsMike Frysinger1-3/+3
A bunch of these paths don't include any headers, and most likely never will, so there's no real need to keep them. This will let us harmonize paths with the top-level Makefile more easily, which will in turn make it easier to move more compile steps there.
2022-11-03Automatic date update in version.inGDB Administrator1-1/+1
2022-11-02arm: PR 29739 Fix typo where ';' should not have been replaced with '@'Christophe Lyon3-3/+3
';' does not always indicate the start of a comment, and commit 8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3 instances of ';' with '@' in expected diagnostics, leading to tests failures. This patch restores the original ';' as needed in these testcases. Fixes bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29739
2022-11-02sim: split CPPFLAGS between build & hostMike Frysinger6-4/+19
In order to merge more common/ files into the top-level, we need to add more host flags to CPPFLAGS, and that conflicts with our current use with build-time tools. So split them apart like we do with all other build flags to avoid the issue.
2022-11-02sim: h8300: switch to cpu for stateMike Frysinger1-394/+299
Rather than rely on pulling out the first cpu from the sim state for cpu state, pass down the active cpu that's already available.
2022-11-02sim: common: change sim_{fetch,store}_register helpers to use void* buffersMike Frysinger37-115/+123
When reading/writing arbitrary data to the system's memory, the unsigned char pointer type doesn't make that much sense. Switch it to void so we align a bit with standard C library read/write functions, and to avoid having to sprinkle casts everywhere.
2022-11-02Fix Cygwin build after 20489ccaJon Turney1-7/+9
Update code under __CYGWIN__ which accesses inferior process information which is now stored in windows_process_info rather than globals.
2022-11-02Fix Cygwin build after bcb9251fJon Turney1-1/+1
Absent _UNICODE being defined (which gdb's Makefile doesn't do), windows.h will always define STARTUPINFO is as STARTUPINFOA, so this cast isn't correct when create_process expects a STARTUPINFOW parameter (i.e. in a Cygwin build). Instead write this as &info_ex.StartupInfo (which is always of the correct type).
2022-11-02x86: drop bogus TbyteJan Beulich2-4/+4
Prior to commit 1cb0ab18ad24 ("x86/Intel: restrict suffix derivation") the Tbyte modifier on the FLDT and FSTPT templates was pointless, as No_ldSuf would have prevented it being accepted. Due to the special nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these insns being accepted in Intel syntax mode even when "tbyte ptr" was present. Restore original behavior by dropping Tbyte there. (Note that these insns in principle should by marked AT&T syntax only, but since they haven't been so far we probably shouldn't change that.)
2022-11-02x86: simplify expressions in update_imm()Jan Beulich1-23/+14
Comparing the sum of the relevant .imm<N> fields against a constant imo makes more obvious what is actually meant. It allows dropping of two static variables, with a 3rd drop requiring two more minor adjustments elsewhere, utilizing that "i" is zeroed first thing in md_assemble(). This also increases the chances of the compiler doing the calculations all in registers.
2022-11-02RISC-V: Fixed the missing $x+arch when adding odd paddings for alignment.Nelson Chu4-38/+67
Consider the case, .option arch, rv32i .option norelax .option arch, +c .byte 1 .align 2 addi a0, zero, 1 Assembler adds $d for the odd .byte, and then adds $x+arch for the alignment. Since norelax, riscv_add_odd_padding_symbol will add the $d and $x for the odd alignment, but accidently remove the $x+arch because it has the same address as $d. Therefore, we will get the unexpected result before applying this patch, .byte 1 # $d .align 2 # odd alignment, $xrv32ic replaced by $d + $x After this patch, the expected result should be, .byte 1 # $d .align 2 # odd alignment, $xrv32ic replaced by $d + $xrv32ic gas/ * config/tc-riscv.c (make_mapping_symbol): If we are adding mapping symbol for odd alignment, then we probably will remove the $x+arch by accidently when it has the same address of $d. Try to add the removed $x+arch back after the $d rather than just $x. (riscv_mapping_state): Updated since parameters of make_mapping_symbol are changed. (riscv_add_odd_padding_symbol): Likewise. (riscv_remove_mapping_symbol): Removed and moved the code into the riscv_check_mapping_symbols. (riscv_check_mapping_symbols): Updated. * testsuite/gas/riscv/mapping-dis.d: Updated and added new testcase. * testsuite/gas/riscv/mapping-symbols.d: Likewise. * testsuite/gas/riscv/mapping.s: Likewise.
2022-11-02Support Intel MSRLISTHu, Lin115-4162/+4284
gas/ChangeLog: * NEWS: Support Intel MSRLIST. * config/tc-i386.c: Add msrlist. * doc/c-i386.texi: Document .msrlist. * testsuite/gas/i386/i386.exp: Add MSRLIST tests. * testsuite/gas/i386/msrlist-inval.l: New test. * testsuite/gas/i386/msrlist-inval.s: Ditto. * testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto. * testsuite/gas/i386/x86-64-msrlist.d: Ditto. * testsuite/gas/i386/x86-64-msrlist.s: Ditto. opcodes/ChangeLog: * i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_6_P_1): New. (X86_64_0F01_REG_0_MOD_3_RM_6_P_3): Ditto. (prefix_table): New entry for msrlist. (x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_6_P_1 and X86_64_0F01_REG_0_MOD_3_RM_6_P_3. * i386-gen.c (cpu_flag_init): Add CPU_MSRLIST_FLAGS and CPU_ANY_MSRLIST_FLAGS. * i386-init.h: Regenerated. * i386-opc.h (CpuMSRLIST): New. (i386_cpu_flags): Add cpumsrlist. * i386-opc.tbl: Add MSRLIST instructions. * i386-tbl.h: Regenerated.
2022-11-02Support Intel WRMSRNSHu, Lin115-4161/+4256
gas/ChangeLog: * NEWS: Support Intel WRMSRNS. * config/tc-i386.c: Add wrmsrns. * doc/c-i386.texi: Document .wrmsrns. * testsuite/gas/i386/i386.exp: Add WRMSRNS tests. * testsuite/gas/i386/wrmsrns-intel.d: New test. * testsuite/gas/i386/wrmsrns.d: Ditto. * testsuite/gas/i386/wrmsrns.s: Ditto. * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto. * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto. opcodes/ChangeLog: * i386-dis.c (PREFIX_0F01_REG_0_MOD_3_RM_6): New. (prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_6. (rm_table): New entry for wrmsrns. * i386-gen.c (cpu_flag_init): Add CPU_WRMSRNS_FLAGS and CPU_ANY_WRMSRNS_FLAGS. (cpu_flags): Add CpuWRMSRNS. * i386-init.h: Regenerated. * i386-opc.h (CpuWRMSRNS): New. (i386_cpu_flags): Add cpuwrmsrns. * i386-opc.tbl: Add WRMSRNS instructions. * i386-tbl.h: Regenerated.
2022-11-02Add handler for more i386_cpu_flagsKong Lingling1-0/+17
gas/ChangeLog: * config/tc-i386.c (cpu_flags_all_zero): Add new ARRAY_SIZE handle. (cpu_flags_equal): Ditto. (cpu_flags_and): Ditto. (cpu_flags_or): Ditto. (cpu_flags_and_not): Ditto.
2022-11-02Support Intel CMPccXADDHaochen Jiang15-4151/+5623
gas/ChangeLog: * NEWS: Support Intel CMPccXADD. * config/tc-i386.c: Add cmpccxadd. (build_modrm_byte): Add operations for Vex.VVVV reg on operand 0 while have memory operand. * doc/c-i386.texi: Document .cmpccxadd. * testsuite/gas/i386/i386.exp: Run CMPccXADD tests. * testsuite/gas/i386/cmpccxadd-inval.s: New test. * testsuite/gas/i386/cmpccxadd-inval.l: Ditto. * testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto. * testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto. * testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto. opcodes/ChangeLog: * i386-dis.c (Mdq): New. (X86_64_VEX_0F38E0): Ditto. (X86_64_VEX_0F38E1): Ditto. (X86_64_VEX_0F38E2): Ditto. (X86_64_VEX_0F38E3): Ditto. (X86_64_VEX_0F38E4): Ditto. (X86_64_VEX_0F38E5): Ditto. (X86_64_VEX_0F38E6): Ditto. (X86_64_VEX_0F38E7): Ditto. (X86_64_VEX_0F38E8): Ditto. (X86_64_VEX_0F38E9): Ditto. (X86_64_VEX_0F38EA): Ditto. (X86_64_VEX_0F38EB): Ditto. (X86_64_VEX_0F38EC): Ditto. (X86_64_VEX_0F38ED): Ditto. (X86_64_VEX_0F38EE): Ditto. (X86_64_VEX_0F38EF): Ditto. (x86_64_table): Add X86_64_VEX_0F38E0, X86_64_VEX_0F38E1, X86_64_VEX_0F38E2, X86_64_VEX_0F38E3, X86_64_VEX_0F38E4, X86_64_VEX_0F38E5, X86_64_VEX_0F38E6, X86_64_VEX_0F38E7, X86_64_VEX_0F38E8, X86_64_VEX_0F38E9, X86_64_VEX_0F38EA, X86_64_VEX_0F38EB, X86_64_VEX_0F38EC, X86_64_VEX_0F38ED, X86_64_VEX_0F38EE, X86_64_VEX_0F38EF. * i386-gen.c (cpu_flag_init): Add CPU_CMPCCXADD_FLAGS and CPU_ANY_CMPCCXADD_FLAGS. (cpu_flags): Add CpuCMPCCXADD. * i386-init.h: Regenerated. * i386-opc.h (CpuCMPCCXADD): New. (i386_cpu_flags): Add cpucmpccxadd. Comment unused for it is actually 0. * i386-opc.tbl: Add Intel CMPccXADD instructions. * i386-tbl.h: Regenerated.
2022-11-02Support Intel AVX-VNNI-INT8Cui,Lili16-457/+1159
gas/ * NEWS: Support Intel AVX-VNNI-INT8. * config/tc-i386.c: Add avx_vnni_int8. * doc/c-i386.texi: Document avx_vnni_int8. * testsuite/gas/i386/avx-vnni-int8-intel.d: New file. * testsuite/gas/i386/avx-vnni-int8.d: Likewise. * testsuite/gas/i386/avx-vnni-int8.s: Likewise. * testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Likewise. * testsuite/gas/i386/x86-64-avx-vnni-int8.d: Likewise. * testsuite/gas/i386/x86-64-avx-vnni-int8.s: Likewise. * testsuite/gas/i386/i386.exp: Run AVX VNNI INT8 tests. opcodes/ * i386-dis.c: (PREFIX_VEX_0F3850) New. (PREFIX_VEX_0F3851): Likewise. (VEX_W_0F3850_P_0): Likewise. (VEX_W_0F3850_P_1): Likewise. (VEX_W_0F3850_P_2): Likewise. (VEX_W_0F3850_P_3): Likewise. (VEX_W_0F3851_P_0): Likewise. (VEX_W_0F3851_P_1): Likewise. (VEX_W_0F3851_P_2): Likewise. (VEX_W_0F3851_P_3): Likewise. (VEX_W_0F3850): Delete. (VEX_W_0F3851): Likewise. (prefix_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851. (vex_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851, delete VEX_W_0F3850 and VEX_W_0F3851. (vex_w_table): Add VEX_W_0F3850_P_0, VEX_W_0F3850_P_1, VEX_W_0F3850_P_2 VEX_W_0F3850_P_3, VEX_W_0F3851_P_0, VEX_W_0F3851_P_1, VEX_W_0F3851_P_2 and VEX_W_0F3851_P_3, delete VEX_W_0F3850 and VEX_W_0F3851. * i386-gen.c: (cpu_flag_init): Add CPU_AVX_VNNI_INT8_FLAGS and CPU_ANY_AVX_VNNI_INT8_FLAGS. (cpu_flags): Add CpuAVX_VNNI_INT8. * i386-opc.h (CpuAVX_VNNI_INT8): New. * i386-opc.tbl: Add Intel AVX_VNNI_INT8 instructions. * i386-init.h: Regenerated. * i386-tbl.h: Likewise.
2022-11-02Support Intel AVX-IFMAHongyu Wang22-4160/+4476
x86: Support Intel AVX-IFMA Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is cleared by default. Without {vex} pseudo prefix, Intel IFMA instructions are encoded with EVEX prefix. {vex} pseudo prefix will turn on VEX encoding for Intel IFMA instructions. gas/ * NEWS: Support Intel AVX-IFMA. * config/tc-i386.c (cpu_arch): Add avx_ifma. * doc/c-i386.texi: Document .avx_ifma. * testsuite/gas/i386/avx-ifma.d: New file. * testsuite/gas/i386/avx-ifma-intel.d: Likewise. * testsuite/gas/i386/avx-ifma.s: Likewise. * testsuite/gas/i386/x86-64-avx-ifma.d: Likewise. * testsuite/gas/i386/x86-64-avx-ifma-intel.d: Likewise. * testsuite/gas/i386/x86-64-avx-ifma.s: Likewise. * testsuite/gas/i386/i386.exp: Run AVX IFMA tests. opcodes/ * i386-dis.c (PREFIX_VEX_0F38B4): New. (PREFIX_VEX_0F38B5): Likewise. (VEX_W_0F38B4_P_2): Likewise. (VEX_W_0F38B5_P_2): Likewise. (prefix_table): Add PREFIX_VEX_0F38B4 and PREFIX_VEX_0F38B5. (vex_table): Add VEX_W_0F38B4_P_2 and VEX_W_0F38B5_P_2. * i386-dis-evex.h: Fold AVX512IFMA entries to AVX-IFMA. * i386-gen.c (cpu_flag_init): Clear the CpuAVX_IFMA bit in CPU_UNKNOWN_FLAGS. Add CPU_AVX_IFMA_FLGAS and CPU_ANY_AVX_IFMA_FLAGS. Add CpuAVX_IFMA to CPU_AVX2_FLAGS. (cpu_flags): Add CpuAVX_IFMA. * i386-opc.h (CpuAVX_IFMA): New. (i386_cpu_flags): Add cpuavx_ifma. * i386-opc.tbl: Add Intel AVX IFMA instructions. * i386-init.h: Regenerated. * i386-tbl.h: Likewise. Co-authored-by: Haochen Jiang <haochen.jiang@intel.com>
2022-11-02Automatic date update in version.inGDB Administrator1-1/+1
2022-11-01opcodes/arm: don't pass non-string literal to printf like functionAndrew Burgess1-2/+3
The earlier commit: commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf Date: Thu Jul 7 13:43:45 2022 +0100 opcodes/arm: add disassembler styling for arm introduced two places where a register name was passed as the format string to the disassembler's fprintf_styled_func callback. This will cause a warning from some compilers, like this: ../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’: ../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security] 6005 | func (stream, dis_style_register, arm_regnames[gpr]); | ^~~~ This commit fixes these by using "%s" as the format string.
2022-11-01opcodes/arm: silence compiler warning about uninitialized variable useAndrew Burgess1-1/+3
The earlier commit: commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf Date: Thu Jul 7 13:43:45 2022 +0100 opcodes/arm: add disassembler styling for arm was causing a compiler warning about a possible uninitialized variable usage within opcodes/arm-dis.c. The problem is in print_mve_unpredictable, and relates to the reason variable, which is set by a switch table. Currently the switch table does cover every valid value, though there is no default case. The variable switched on is passed in as an argument to the print_mve_unpredictable function. Looking at how print_mve_unpredictable is used, there is only one use, the second argument is the one that is used for the switch table, looking at how this argument is set, I don't believe it is possible for this argument to take an invalid value. So, I think the compiler warning is a false positive. As such, my proposed solution is to initialize the reason variable to the string "??", this will silence the warning, and the "??" string should never end up being printed.
2022-11-01opcodes/arm: add disassembler styling for armAndrew Burgess3-1004/+1633
This commit adds disassembler styling for the ARM architecture. The ARM disassembler is driven by several instruction tables, e.g. cde_opcodes, coprocessor_opcodes, neon_opcodes, etc The type for elements in each table can vary, but they all have one thing in common, a 'const char *assembler' field. This field contains a string that describes the assembler syntax of the instruction. Embedded within that assembler syntax are various escape characters, prefixed with a '%'. Here's an example of a very simple instruction from the arm_opcodes table: "pld\t%a" The '%a' indicates a particular type of operand, the function print_insn_arm processes the arm_opcodes table, and includes a switch statement that handles the '%a' operand, and takes care of printing the correct value for that instruction operand. It is worth noting that there are many print_* functions, each function handles a single *_opcodes table, and includes its own switch statement for operand handling. As a result, every *_opcodes table uses a different mapping for the operand escape sequences. This means that '%a' might print an address for one *_opcodes table, but in a different *_opcodes table '%a' might print a register operand. Notice as well that in our example above, the instruction mnemonic 'pld' is embedded within the assembler string. Some instructions also include comments within the assembler string, for example, also from the arm_opcodes table: "nop\t\t\t@ (mov r0, r0)" here, everything after the '@' is a comment that is displayed at the end of the instruction disassembly. The next complexity is that the meaning of some escape sequences is not necessarily fixed. Consider these two examples from arm_opcodes: "ldrex%c\tr%12-15d, [%16-19R]" "setpan\t#%9-9d" Here, the '%d' escape is used with a bitfield modifier, '%12-15d' in the first instruction, and '%9-9d' in the second instruction, but, both of these are the '%d' escape. However, in the first instruction, the '%d' is used to print a register number, notice the 'r' immediately before the '%d'. In the second instruction the '%d' is used to print an immediate, notice the '#' just before the '%d'. We have two problems here, first, the '%d' needs to know if it should use register style or immediate style, and secondly, the 'r' and '#' characters also need to be styled appropriately. The final thing we must consider is that some escape codes result in more than just a single operand being printed, for example, the '%q' operand as used in arm_opcodes ends up calling arm_decode_shift, which can print a register name, a shift type, and a shift amount, this could end up using register, sub-mnemonic, and immediate styles, as well as the text style for things like ',' between the different parts. I propose a three layer approach to adding styling: (1) Basic state machine: When we start printing an instruction we should maintain the idea of a 'base_style'. Every character from the assembler string will be printed using the base_style. The base_style will start as mnemonic, as each instruction starts with an instruction mnemonic. When we encounter the first '\t' character, the base_style will change to text. When we encounter the first '@' the base_style will change to comment_start. This simple state machine ensures that for simple instructions the basic parts, except for the operands themselves, will be printed in the correct style. (2) Simple operand styling: For operands that only have a single meaning, or which expand to multiple parts, all of which have a consistent meaning, then I will simply update the operand printing code to print the operand with the correct style. This will cover a large number of the operands, and is the most consistent with how styling has been added to previous architectures. (3) New styling syntax in assembler strings: For cases like the '%d' that I describe above, I propose adding a new extension to the assembler syntax. This extension will allow me to temporarily change the base_style. Operands like '%d', will then print using the base_style rather than using a fixed style. Here are the two examples from above that use '%d', updated with the new syntax extension: "ldrex%c\t%{R:r%12-15d%}, [%16-19R]" "setpan\t%{I:#%9-9d%}" The syntax has the general form '%{X:....%}' where the 'X' character changes to indicate a different style. In the first instruction I use '%{R:...%}' to change base_style to the register style, and in the second '%{I:...%}' changes base_style to immediate style. Notice that the 'r' and '#' characters are included within the new style group, this ensures that these characters are printed with the correct style rather than as text. The function decode_base_style maps from character to style. I've included a character for each style for completeness, though only a small number of styles are currently used. I have updated arm-dis.c to the above scheme, and checked all of the tests in gas/testsuite/gas/arm/, and the styling looks reasonable. There are no regressions on the ARM gas/binutils/ld tests that I can see, so I don't believe I've changed the output layout at all. There were two binutils tests for which I needed to force the disassembler styling off. I can't guarantee that I've not missed some untested corners of the disassembler, or that I might have just missed some incorrectly styled output when reviewing the test results, but I don't believe I've introduced any changes that could break the disassembler - the worst should be some aspect is not styled correctly.
2022-11-01opcodes/arm: use '@' consistently for the comment characterAndrew Burgess237-3548/+3548
Looking at the ARM disassembler output, every comment seems to start with a ';' character, so I assumed this was the correct character to start an assembler comment. I then spotted a couple of places where there was no ';', but instead, just a '@' character. I thought that this was a case of a missing ';', and proposed a patch to add the missing ';' characters. Turns out I was wrong, '@' is actually the ARM assembler comment character, while ';' is the statement separator. Thus this: nop ;@ comment is two statements, the first is the 'nop' instruction, while the second contains no instructions, just the '@ comment' comment text. This: nop @ comment is a single 'nop' instruction followed by a comment. And finally, this: nop ; comment is two statements, the first contains the 'nop' instruction, while the second contains the instruction 'comment', which obviously isn't actually an instruction at all. Why this matters is that, in the next commit, I would like to add libopcodes syntax styling support for ARM. The question then is how should the disassembler style the three cases above? As '@' is the actual comment start character then clearly the '@' and anything after it can be styled as a comment. But what about ';' in the second example? Style as text? Style as a comment? And the third example is even harder, what about the 'comment' text? Style as an instruction mnemonic? Style as text? Style as a comment? I think the only sensible answer is to move the disassembler to use '@' consistently as its comment character, and remove all the uses of ';'. Then, in the next commit, it's obvious what to do. There's obviously a *lot* of tests that get updated by this commit, the only actual code changes are in opcodes/arm-dis.c.
2022-11-01Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2024-09-13 22:40:32 +0000