aboutsummaryrefslogtreecommitdiff
path: root/gas/config
AgeCommit message (Collapse)AuthorFilesLines
2021-06-24gas: update csect alignment for PPC prefixed instructions on XCOFFClément Chigot1-0/+5
Power10 prefixed instructions must not cross 64-byte boundaries. This is already handled. However, on XCOFF, the csect must be updated to match the new alignment. * config/tc-ppc.c (md_assemble): Update ppc_current_csect alignment when finding prefixed instructions.
2021-06-22picojava assembler and disassembler fixesAlan Modra1-4/+1
Commit 54758c3e398d made changes to the picojava support based on https://sourceware.org/pipermail/binutils/2005-November/045136.html An update from picojava to picojava II, I think. Unfortunately the patch neglected any changes to the gas testsuite, resulting in "FAIL: pj" since that date. This patch makes a few relatively simple changes to cure the regression. gas/ * config/tc-pj.c (md_apply_fix): Apply PJ_CODE_REL32 relocs. * testsuite/gas/pj/ops.s: Update jsr, ret, getstatic, putstatic, getfield, putfield, invokevirtual, invokespecial, invokestatic, invokeinterface, goto_w, jsr_w assembly. Delete version 1 picojava opcodes. * testsuite/gas/pj/ops.d: Match expected output. opcodes/ * pj-dis.c (print_insn_pj): Don't print trailing tab. Do print separator for pcrel insns.
2021-06-19ubsan errors when 32-bit bfdAlan Modra1-3/+3
A shift count exceeding the size of the value is undefined behaviour, and so is negating a signed LONG_MIN. * config/tc-z80.c (signed_overflow, unsigned_overflow): Avoid UB.
2021-06-17Fix an assertion failure in the AArch64 assembler triggered by incorrect ↵Nick Clifton1-3/+12
instruction syntax. PR 27904 * config/tc-aarch64.c (ldst_lo12_determine_real_reloc_type): Generate a syntax error message if the reloc qualifier does not match the instruction's size.
2021-06-17gas: handle csect in bss section for XCOFFClément Chigot1-3/+7
Latest gcc versions are now generating csects instead of .lcomm for bss symbols. Some adjustements are needed in order to handle them. * config/tc-ppc.c (md_begin): Create bss section with dummy symbol. (ppc_frob_symbol): Output XTY_CM for bss csects. (ppc_fix_adjustable): Adjust condition to avoid bss csects.
2021-06-17gas: ensure sections contents is zero for BFD_RELOC_PPC*_TLSM on XCOFF.Clément Chigot1-5/+12
AIX ld expects the section contents for relocations BFD_RELOC_PPC_TLSM or BFD_RELOC_PPC64_TLSM to be zero. Actually, it seems to be the case for all the TLS relocations generated by AIX assembly but only these two are mandatory. * config/tc-ppc.c (md_apply_fix): Adjust addend to nullify section contents for BFD_RELOC_PPC_TLSM or BFD_RELOC_PPC64_TLSM. * testsuite/gas/ppc/xcoff-tlsm-32.d: New test. * testsuite/gas/ppc/xcoff-tlsm-64.d: New test. * testsuite/gas/ppc/xcoff-tlsm.s: New test. * testsuite/gas/ppc/aix.exp: Run new tests.
2021-06-15x86: bring "gas --help" output for --32 etc in sync with realityJan Beulich1-3/+7
The testsuite uses the output to determine whether BFD64 is in effect. --x32 is supported for ELF only; don't advertise it for PE/COFF. --64 is also supported for Mach-O; advertise it. Adjust the testsuite's BFD64 check accordingly. Also replace "code" by "object", since it's the object format that the options primarily control. It's also _initial_ code bitness, but this can be changed by directives.
2021-06-15x86: simplify .dispNN settingJan Beulich1-51/+17
First of all eliminate the disp{16,32,32s} static variables, which are used solely for setting a temporary variable in build_modrm_byte(). The effect there can be had without use of such a temporary and without operand_type_or(), by just setting the single bit each that needs setting. Then use operand_type_and_not(..., anydisp) when all dispNN bits want clearing together.
2021-06-15x86: slightly simplify offset_in_range()Jan Beulich1-2/+2
Applying a mask with all bits set (or its inverse, with hence all bits clear) won't alter the result (or won't trigger the warning). Re-arrange the code to eliminate two more of the somewhat odd (2 << width_minus_1) constructs.
2021-06-15x86: harmonize disp with imm handlingJan Beulich1-23/+28
Certain disp values may trigger "... shortened to ..." warnings when equivalent imm ones don't. In some of the cases there are also differences (for non-64-bit code) between BFD64 and !BFD64 builds. The resulting encodings (i.e. use [or not] of the shorter disp8 / imm8 forms) are also different in some cases. Make this handling consistent. Note that using equivalent 16-bit mode displacements / immediates continues to expose entirely different behavior (see the disp-imm-16 testcase added by an earlier patch). This may want to be the subject of further changes, but it'll then quickly become obvious that e.g. keying use of extend_to_32bit_address() to non-64-bit mode isn't appropriate either: Once we allow wrapping operands, we would better do so consistently, in which case all of this would need to become dependent upon address or operand size instead of mode.
2021-06-15x86: make offset_in_range()'s warning contents useful (again)Jan Beulich1-6/+2
In case there is something which gets shortened (perhaps only on a BFD64 build targeting a 32-bit binary), seeing the full original value is often helpful to understand what's actually going wrong. Of course for non-64-bit binaries we better wouldn't be seeing such warnings at all, as they're often indicative of a behavioral difference between BFD64 and !BFD64 builds. Prior to "gas: drop sprint_value()", which introduced the use of bfd_sprintf_vma(), the output had other shortcomings.
2021-06-15x86: off-by-1 in offset_in_range()Jan Beulich1-1/+1
Just like e.g. 0x10000 triggers a warning for size 2, -0x10000 ought to as well. Note that some of the encodings produced aren't ones one would expect, and hence the generated code is not being checked for in the new testcases.
2021-06-15x86: permit parenthesized expressions again as addressing scale factorJan Beulich1-2/+6
The description of e68c3d59acd0 ("x86: better respect quotes in parse_operands()") wrongly states: "In i386_att_operand(), which needs adjustment to remain in sync, besides respecting double quotes now, also change the logic such that we don't count parentheses anymore: Finding any opening or closing parenthesis or any double quote means we're done, because the subsequent parsing code wouldn't accept (extra) instances of these anyway." I didn't pay attention to the possibility of the scale factor being specified as an expression, which may contain parentheses. Thanks to Martin for pointing this out. Restore prior behavior or matching parentheses (backwards), while giving the variable a more suitable name. Note that this simple and immediate fix is not ging to be enough: This expression could itself involve quoted symbols. However, to address this backwards parsing needs to be done away with altogether here (such that parentheses which are part of such a quoted symbol name can also properly be accounted for), which is going to be a more intrusive change.
2021-06-11x86: Always define TC_PARSE_CONS_EXPRESSIONH.J. Lu2-3/+6
Always define TC_PARSE_CONS_EXPRESSION to properly wrap constants for all x86 targets. * config/tc-i386.c (x86_cons): Handle GOT/PLT relocations only if needed. * config/tc-i386.h (TC_PARSE_CONS_EXPRESSION): Always define.
2021-06-11RISC-V: Update the riscv_opts.[rvc|rve] in the riscv_set_arch.Nelson Chu1-10/+8
We also need to update the riscv_opts.[rvc|rve] for elf attributes. Otherwise, the following case will fail, $ cat cadd.s .attribute arch, "rv64gc" c.add a0, a1 $ riscv64-unknown-elf-as cadd.s -o cadd.o cadd.s: Assembler messages: cadd.s:2: Error: illegal operands `c.add a0,a1 After applying this patch, $ riscv64-unknown-elf-as cadd.s -o cadd.o $ riscv64-unknown-elf-objdump -d cadd.o cadd.o: file format elf64-littleriscv Disassembly of section .text: 0000000000000000 <.text>: 0: 952e add a0,a0,a1 ... gas/ * config/tc-riscv.c (riscv_set_arch): Call riscv_set_rvc and riscv_set_rve both for -march and elf attributes. (riscv_after_parse_args): Likewise.
2021-06-10arm: avoid "shadowing" of glibc function nameJan Beulich1-16/+16
Old enough glibc has an (unguarded) declaration of index() in string.h, which triggers a "shadows a global declaration" warning.
2021-06-10arm: fix array-out-of-bounds upon register parsing errorJan Beulich1-1/+2
Despite the comment ahead of the enum explicitly pointing out the need to also update the corresponding array, 1b8833198c0 ("Add support for MVE instructions: vcmp and vpt") failed to do so. Oddly enough the issue appears to be spotted only by rather old gcc (4.3-ish in my case).
2021-06-10x86: suppress LEA optimization in a specific 16-bit caseJan Beulich1-0/+7
In 16-bit mode a 16-bit address size LEA with a 16-bit displacement and a 32-bit destination is shorter to encode than the corresponding MOV. Commit fe134c656991 ("x86: optimize LEA")'s promise was to only do the transformation when the encoding size wouldn't grow, i.e. it did go a little too far. Restrict this specific case of the transformation to -O2.
2021-06-08x86: minor improvements to optimize_imm() (part II)Jan Beulich1-3/+2
Don't kind-of-open-code fits_in_unsigned_{word,long}().
2021-06-08x86: minor improvements to optimize_disp() (part II)Jan Beulich1-7/+5
- Don't kind-of-open-code fits_in_unsigned_{word,long}(). - Fold two if()s both using fits_in_unsigned_long().
2021-06-08x86-64: avoid bogus warnings with 32-bit addressingJan Beulich1-0/+2
With optimize_disp() adjusting i.types[].bitfield.disp after adjusting the value to be used as displacement, it better also stores the updated value, to avoid subsequent "... shortened to ..." warnings. Note how optimize_imm() already does so. The -0xffffffff tests being added expose a separate issue: The encoding chosen should be 1 for ModR/M.mod, not 2. This will want to be taken care of, but not right here. This at the same time addresses a similar warning and demonstrates a similar encoding issue with 16-bit addressing. Since it was omitted when introducing the lea16-optimize test, add a plain lea16 one to also cover this.
2021-06-08x86: minor improvements to optimize_disp() (part I)Jan Beulich1-11/+13
- Do the zero checking first - there's no point in doing anything else in this case. - Drop two pointless & where just before it was checked that the respective bits are clear already anyway.
2021-06-07x86: honor quoted figure braces in i386_att_operand()Jan Beulich1-8/+32
When AVX512 support was added, symbol quotation was not paid attention to. Just like the (base,index,scale) specifier gets parsed from the end of the expression, the {...} also wants parsing from the end; in no case is the first { found a guarantee of a masking or broadcasting specifier.
2021-06-07x86: better respect quotes in parse_operands()Jan Beulich1-14/+23
When d02603dc201f ("Allow symbol and label names to be enclosed in double quotes") added the check for a double quote to the loop body there, it didn't go quite far enough: Parentheses inside quotes shouldn't be counted, and character restrictions also shouldn't apply inside quoted regions. In i386_att_operand(), which needs adjustment to remain in sync, besides respecting double quotes now, also change the logic such that we don't count parentheses anymore: Finding any opening or closing parenthesis or any double quote means we're done, because the subsequent parsing code wouldn't accept (extra) instances of these anyway. Note that in parse_operands() this mimics get_symbol_name()'s questionable behavior of treating \ specially only when ahead of ". (The behavior is suspicious because the meaning of \\ then is ambiguous. It is in particular impossible to have a (quoted) symbol name end in a single \.) I would have used get_symbol_name() here, if that didn't require fiddling with input_line_pointer.
2021-06-07x86: allow unary operators to start a memory operandJan Beulich1-14/+3
So far only - was permitted, but +, !, and ~ ought to be treated the same. Rather than adding them to digit_chars[], which was at least odd to have held - so far, drop this array and its wrapper macro for being used just once. While adjusting this logic, also include [ in the characters which may start a displacement expression - gas generally treats [] as equivalent to ().
2021-06-07x86: make symbol quotation check consistent in i386_att_operand()Jan Beulich1-7/+10
When d02603dc201f ("Allow symbol and label names to be enclosed in double quotes") added the check for a leading double quote to i386_att_operand(), it missed a second similar check after having found a segment override. To avoid the two checks going out of sync again, introduce an inline helper.
2021-06-07x86: correct absolute branch check with segment overrideJan Beulich1-9/+9
This needs to happen before checking of what may legitimately start a memory operand (like is done when there's no segment override). Plus a second '*' shouldn't be permitted when one was already found before the segment override.
2021-06-07x86/Intel: drop unnecessary bracket matching from parse_operands()Jan Beulich1-13/+3
While subsequent processing in AT&T mode relies on this simplistic early checking, Intel mode hasn't been for quite a long time (or perhaps never really did).
2021-06-07x86: remove pointless 2nd parameter from check_VecOperations()Jan Beulich2-6/+5
In the one case where non-NULL gets passed, passing NULL has the same effect. Hence the parameter is not needed at all.
2021-06-07x86: immediate operands don't allow for vector operationsJan Beulich1-10/+0
Neither masking nor broadcast are possible here, and RC/SAE get dealt with elsewhere. This also fixes gas crashes (i.e. "Fatal error: unable to continue with assembly"), since the return path being removed failed to restore input_line_pointer from save_input_line_pointer.
2021-06-07ix86: wrap constantsJan Beulich1-6/+28
Non-64-bit code should get handled the same with or without BFD64. This wasn't the case though in a number of situations (and quite likely there are more that I haven't spotted yet). It's not very nice to tie the check in md_apply_fix() to object_64bit, but afaict at that time we have no record anymore of the mode an insn was assembled in (it might also have been data). This doesn't look to be the first inconsistency of this kind, though. In x86_cons() it's even less clear what the right approach would be: flag_code shouldn't matter for data emission, but instead we'd need to know from which mode(s) the data actually gets accessed. On this basis, signed_cons() also gets adjusted.
2021-05-29MIPS/opcodes: Do not use CP0 register names for control registersMaciej W. Rozycki1-4/+5
The CP0 control register set has never been defined, however encodings for the CFC0 and CTC0 instructions remained available for implementers up until the MIPS32 ISA declared them invalid and causing the Reserved Instruction exception[1]. Therefore we handle them for both assembly and disassembly, however in the latter case the names of CP0 registers from the regular set are incorrectly printed if named registers are requested. This is because we do not define separate operand classes for coprocessor regular and control registers respectively, which means the disassembler has no way to tell the two cases apart. Consequently nonsensical disassembly is produced like: cfc0 v0,c0_random Later the MIPSr5 ISA reused the encodings for XPA ASE MFHC0 and MTHC0 instructions[2] although it failed to document them in the relevant opcode table until MIPSr6 only. Correct the issue then by defining a new register class, OP_REG_CONTROL, and corresponding operand codes, `g' and `y' for the two positions in the machine instruction a control register operand can take. Adjust the test cases affected accordingly. While at it swap the regular MIPS opcode table "cfc0" and "ctc0" entries with each other so that they come in the alphabetical order. References: [1] "MIPS32 Architecture For Programmers, Volume II: The MIPS32 Instruction Set", MIPS Technologies, Inc., Document Number: MD00086, Revision 1.00, August 29, 2002, Table A-9 "MIPS32 COP0 Encoding of rs Field", p. 242 [2] "MIPS Architecture For Programmers, Volume II-A: The MIPS32 Instruction Set", MIPS Technologies, Inc., Document Number: MD00086, Revision 5.04, December 11, 2013, Section 3.2 "Alphabetical List of Instructions", pp. 195, 216 include/ * opcode/mips.h: Document `g' and `y' operand codes. (mips_reg_operand_type): Add OP_REG_CONTROL enumeration constant. gas/ * tc-mips.c (convert_reg_type) <OP_REG_CONTROL>: New case. (macro) <M_TRUNCWS, M_TRUNCWD>: Use the `g' rather than `G' operand code. opcodes/ * mips-dis.c (print_reg) <OP_REG_COPRO>: Move control register handling code over to... <OP_REG_CONTROL>: ... this new case. * mips-opc.c (decode_mips_operand) <'g', 'y'>: New cases. (mips_builtin_opcodes): Update "cfc1", "ctc1", "cttc1", "cttc2", "cfc0", "ctc0", "cfc2", "ctc2", "cfc3", and "ctc3" entries replacing the `G' operand code with `g'. Update "cftc1" and "cftc2" entries replacing the `E' operand code with `y'. * micromips-opc.c (decode_micromips_operand) <'g'>: New case. (micromips_opcodes): Update "cfc1", "cfc2", "ctc1", and "ctc2" entries replacing the `G' operand code with `g'. binutils/ * testsuite/binutils-all/mips/mips-xpa-virt-1.d: Correct CFC0 operand disassembly. * testsuite/binutils-all/mips/mips-xpa-virt-3.d: Likewise.
2021-05-29MIPS/GAS: Use FCSR rather than RA with CFC1/CTC1Maciej W. Rozycki1-4/+6
Fix an issue caused by commit f9419b056fe2 ("MIPS gas: code cleanup"), <https://sourceware.org/ml/binutils/2002-05/msg00192.html>, and replace the incorrect use of RA with the CFC1 and CTC1 instructions with FCSR. While the register referred by its number is $31 in both cases, these instructions operate on the floating-point control register file rather than general-purpose registers. gas/ * config/tc-mips.c (FCSR): New macro. (macro) <M_TRUNCWS, M_TRUNCWD>: Use it in place of RA.
2021-05-28x86: Restore PC16 relocation overflow checkH.J. Lu1-37/+18
The x86-64 psABI has --- A program or object file using R_X86_64_8, R_X86_64_16, R_X86_64_PC16 or R_X86_64_PC8 relocations is not conformant to this ABI, these relocations are only added for documentation purposes. --- Since x86 PC16 relocations have been used for 16-bit programs in an ELF32 or ELF64 container, PC16 relocation should wrap-around in 16-bit address space. Revert commit a7664973b24a242cd9ea17deb5eaf503065fc0bd Author: Jan Beulich <jbeulich@suse.com> Date: Mon Apr 26 10:41:35 2021 +0200 x86: correct overflow checking for 16-bit PC-relative relocs and xfail the related tests. Also revert commit 50c95a739c91ae70cf8481936611aa1f5397a384 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed May 26 12:13:13 2021 -0700 x86: Propery check PC16 reloc overflow in 16-bit mode instructions while keeping PR ld/27905 tests for PC16 relocation in 16-bit programs. bfd/ PR ld/27905 * elf32-i386.c: Don't include "libiberty.h". (elf_howto_table): Revert commits a7664973b24 and 50c95a739c9. (elf_i386_rtype_to_howto): Revert commit 50c95a739c9. (elf_i386_info_to_howto_rel): Likewise. (elf_i386_tls_transition): Likewise. (elf_i386_relocate_section): Likewise. * elf64-x86-64.c (x86_64_elf_howto_table): Revert commits a7664973b24 and 50c95a739c9. (elf_x86_64_rtype_to_howto): Revert commit 50c95a739c9. * elfxx-x86.c (_bfd_x86_elf_parse_gnu_properties): Likewise. * elfxx-x86.h (elf_x86_obj_tdata): Likewise. (elf_x86_has_code16): Likewise. binutils/ PR ld/27905 * readelf.c (decode_x86_feature_2): Revert commit 50c95a739c9. gas/ PR ld/27905 * config/tc-i386.c (set_code_flag): Revert commit 50c95a739c9. (set_16bit_gcc_code_flag): Likewise. (x86_cleanup): Likewise. * testsuite/gas/i386/code16-2.d: Updated. * testsuite/gas/i386/x86-64-code16-2.d: Likewise. include/ PR ld/27905 * elf/common.h (GNU_PROPERTY_X86_FEATURE_2_CODE16): Removed. ld/ PR ld/27905 * testsuite/ld-i386/pcrel16-2.d: xfail. * testsuite/ld-x86-64/pcrel16-2.d: Likewise.
2021-05-27nds32: __builtin_strncpy bound equals destination sizeAlan Modra1-8/+8
* config/tc-nds32.c (do_pseudo_push_bhwd, do_pseudo_pop_bhwd), (do_pseudo_pusha, do_pseudo_pushi): Avoid fortify strncpy bound error.
2021-05-26x86: Propery check PC16 reloc overflow in 16-bit mode instructionsH.J. Lu1-18/+37
commit a7664973b24a242cd9ea17deb5eaf503065fc0bd Author: Jan Beulich <jbeulich@suse.com> Date: Mon Apr 26 10:41:35 2021 +0200 x86: correct overflow checking for 16-bit PC-relative relocs caused linker failure when building 16-bit program in a 32-bit ELF container. Update GNU_PROPERTY_X86_FEATURE_2_USED with #define GNU_PROPERTY_X86_FEATURE_2_CODE16 (1U << 12) to indicate that 16-bit mode instructions are used in the input object: https://groups.google.com/g/x86-64-abi/c/UvvXWeHIGMA to indicate that 16-bit mode instructions are used in the object to allow linker to properly perform relocation overflow check for 16-bit PC-relative relocations in 16-bit mode instructions. 1. Update x86 assembler to always generate the GNU property note with GNU_PROPERTY_X86_FEATURE_2_CODE16 for .code16 in ELF object. 2. Update i386 and x86-64 linkers to use 16-bit PC16 relocations if input object is marked with GNU_PROPERTY_X86_FEATURE_2_CODE16. bfd/ PR ld/27905 * elf32-i386.c: Include "libiberty.h". (elf_howto_table): Add 16-bit R_386_PC16 entry. (elf_i386_rtype_to_howto): Add a BFD argument. Use 16-bit R_386_PC16 if input has 16-bit mode instructions. (elf_i386_info_to_howto_rel): Update elf_i386_rtype_to_howto call. (elf_i386_tls_transition): Likewise. (elf_i386_relocate_section): Likewise. * elf64-x86-64.c (x86_64_elf_howto_table): Add 16-bit R_X86_64_PC16 entry. (elf_x86_64_rtype_to_howto): Use 16-bit R_X86_64_PC16 if input has 16-bit mode instructions. * elfxx-x86.c (_bfd_x86_elf_parse_gnu_properties): Set elf_x86_has_code16 if relocatable input is marked with GNU_PROPERTY_X86_FEATURE_2_CODE16. * elfxx-x86.h (elf_x86_obj_tdata): Add has_code16. (elf_x86_has_code16): New. binutils/ PR ld/27905 * readelf.c (decode_x86_feature_2): Support GNU_PROPERTY_X86_FEATURE_2_CODE16. gas/ PR ld/27905 * config/tc-i386.c (set_code_flag): Update x86_feature_2_used with GNU_PROPERTY_X86_FEATURE_2_CODE16 for .code16 in ELF object. (set_16bit_gcc_code_flag): Likewise. (x86_cleanup): Always generate the GNU property note if x86_feature_2_used isn't 0. * testsuite/gas/i386/code16-2.d: New file. * testsuite/gas/i386/code16-2.s: Likewise. * testsuite/gas/i386/x86-64-code16-2.d: Likewise. * testsuite/gas/i386/i386.exp: Run code16-2 and x86-64-code16-2. include/ PR ld/27905 * elf/common.h (GNU_PROPERTY_X86_FEATURE_2_CODE16): New. ld/ PR ld/27905 * testsuite/ld-i386/code16.d: New file. * testsuite/ld-i386/code16.t: Likewise. * testsuite/ld-x86-64/code16.d: Likewise. * testsuite/ld-x86-64/code16.t: Likewise. * testsuite/ld-i386/i386.exp: Run code16. * testsuite/ld-x86-64/x86-64.exp: Likewise.
2021-05-26RISC-V: Allow to link the objects with unknown prefixed extensions.Nelson Chu1-0/+1
Since the policies of GNU and llvm toolchain are different for now, current binutils mainline cannot accept any draft extensions, including rvv, zfh, .... The Clang/LLVM allows these draft stuff on mainline, but the GNU ld might be used with them, so this causes the link time problems. The patch allows ld to link the objects with unknown prefixed extensions, which are probably generated by LLVM or customized toolchains. bfd/ * elfxx-riscv.h (check_unknown_prefixed_ext): New bool. * elfxx-riscv.c (riscv_parse_prefixed_ext): Do not check the prefixed extension name if check_unknown_prefixed_ext is false. * elfnn-riscv.c (riscv_merge_arch_attr_info): Set check_unknown_prefixed_ext to false for linker. gas/ * config/tc-riscv.c (riscv_set_arch): Set check_unknown_prefixed_ext to true for assembler.
2021-05-25Arm: Fix forward thumb references [PR gas/25235]Tamar Christina1-1/+10
When assembling a forward reference the symbol will be unknown and so during do_t_adr we cannot set the thumb bit. The bit it set so early to prevent relaxations that are invalid. i.e. relaxing a Thumb2 to Thumb1 insn when the symbol is Thumb. But because it's done so early we miss the case for forward references. This patch changes it so that we additionally check the thumb bit during the internal relocation processing. In principle we should be able to only set the bit during reloc processing but that would require changes to the other relocations that the instruction could be relaxed to. This approach still allows early relaxations (which means that we have less iteration of internal reloc processing) while still fixing the forward reference case. gas/ChangeLog: 2021-05-24 Tamar Christina <tamar.christina@arm.com> PR gas/25235 * config/tc-arm.c (md_convert_frag): Set LSB when Thumb symbol. (relax_adr): Thumb symbols 4 bytes. * testsuite/gas/arm/pr25235.d: New test. * testsuite/gas/arm/pr25235.s: New test.
2021-05-24RISC-V: PR25212, Report errors for invalid march and mabi combinations.Nelson Chu1-0/+18
This patch clarify the following invalid combinations of march and mabi, * ilp32f/lp64f abi without f extension. * ilp32d/lp64d abi without d extension. * ilp32q/lp64q abi without q extension. * e extension with any abi except ilp32e GNU assembler reports errors when finding the above invalid combinations. But LLVM-MC reports warnings and ignores these invalid cases. It help to set the correct ilp32/lp64/ilp32e abi according to rv32/rv64/rve. This looks good and convenient, so perhaps we can do the same things. However, if you don't set the mabi, GNU assembler also try to set the suitable ABI according to march/elf-attribute. Compared to LLVM-MC, we will choose double/quad abi if d/f extension is set. gas/ PR 25212 * config/tc-riscv.c (riscv_set_abi_by_arch): If -mabi isn't set, we will choose ilp32e abi for rv32e. Besides, report errors for the invalid march and mabi combinations. * testsuite/gas/riscv/mabi-attr-rv32e.s: New testcase. Only accept ilp32e abi for rve extension. * testsuite/gas/riscv/mabi-fail-rv32e-lp64f.d: Likewise. * testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l: Likewise. * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.d: Likewise. * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise. * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise. * testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise. Renamed all mabi testcases to their march-mabi settings.
2021-05-22Re: Fix offset for ia64 PCREL60B relocation on HP-UXAlan Modra1-2/+8
PR 25599 * config/tc-ia64.c (emit_one_bundle): Expand comment for HP-UX adjustment. Add assertion. * testsuite/gas/ia64/reloc-mlx.d: Pass when slot 2 specified for PCREL60B.
2021-05-20Fix overflow detection in the Z80 assembler.Sergey Belyashov1-8/+24
* config/tc-z80.c (emit_data_val): Warn on constant overflow. (signed_overflow): New function. (unsigned_overflow): New function. (is_overflow): Use new functions. (md_apply_fix): Use signed_overflow. * testsuite/gas/z80/ez80_adl_suf.d: Fix test. * testsuite/gas/z80/ez80_isuf.s: Likewise. * testsuite/gas/z80/ez80_z80_suf.d: Likewise.
2021-05-19Fix offset for ia64 PCREL60B relocation on HP-UXJohn David Anglin1-1/+10
gas/ChangeLog: 2021-05-19 John Buddery <jvb@cyberscience.com> PR 25599 * config/tc-ia64.c (emit_one_bundle): Increment fixup offset by one for PCREL60B relocation on HP-UX.
2021-05-17arm: Fix bugs with MVE vmov from two GPRs to vector lanesAlex Coplan1-2/+2
The initial problem I wanted to fix here is that GAS was rejecting MVE instructions such as: vmov q3[2], q3[0], r2, r2 with: Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2' which is incorrect; such instructions are valid. Note that for moves in the other direction, e.g.: vmov r2, r2, q3[2], q3[0] GAS is correct in rejecting this as it does not make sense to move both lanes into the same register (the Arm ARM says this is CONSTRAINED UNPREDICTABLE). After fixing this issue, I added assembly/disassembly tests for these vmovs. This revealed several disassembly issues, including incorrectly marking the moves into vector lanes as UNPREDICTABLE, and disassembling many of the vmovs as vector loads. These are now fixed. gas/ChangeLog: * config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving into the same GPR twice. * testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message. * testsuite/gas/arm/mve-vmov-3.d: New test. * testsuite/gas/arm/mve-vmov-3.s: New test. opcodes/ChangeLog: * arm-dis.c (mve_opcodes): Fix disassembly of MVE_VMOV2_GP_TO_VEC_LANE when idx == 1. (is_mve_encoding_conflict): MVE vector loads should not match when P = W = 0. (is_mve_unpredictable): It's not unpredictable to use the same source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).
2021-05-11Report illegal Z80 load instructions.Sergey Belyashov1-0/+2
PR 27823 * config/tc-z80.c (emit_ld_r_m): Report an illegal load instruction. * testsuite/gas/z80/ill_ops.s: New test source file. * testsuite/gas/z80/ill_ops.d: New test driver. * testsuite/gas/z80/ill_ops.l: New test error output.
2021-05-10Add support for 8-bit and 24-bit shifts in the z80 assembler.Sergey Belyashov1-0/+17
PR 27415 * config/tc-z80.c (emit_data_val): Add support for 8-bit and 24-bit shifts. * testsuite/gas/z80/z80_reloc.a: Update tests. * testsuite/gas/z80/z80_reloc.d: Update expected disassembly.
2021-05-07Add a generic .bss directive for ELF based targets.Nick Clifton2-14/+36
PR 3136 * config/obj-elf.c (elf_pseudo_table): Add entry for .bss. (obj_elf_bss): New function. Change to the .bss section. Support an optional subsection number. (obj_elf_change_section): Call obj_elf_section_change_hook. (obj_elf_section): Likewise. (obj_elf_data): Likewise. (obj_elf_text): Likewise. (obj_elf_struct): Likewise. (obj_elf_subsection): Likewise. (obj_elf_previous): Likewise. * config/obj-elf.h (obj_elf_bss): Prototype. * doc/as.texi (Bss): New node.
2021-05-07Fix .dwsect generation for XCOFF. Handle .function generated with DWARF on ↵Cl?ment Chigot3-5/+82
XCOFF. gas * config/tc-ppc.c (ppc_function): Update comment for fifth argument. (ppc_frob_symbol): Remove ppc_last_function check. Make sure coff_last_function is reset. Correctly set fsize when not provided in .function. * testsuite/gas/ppc/aix.exp: New tests. * testsuite/gas/ppc/xcoff-function-1-32.d: New test. * testsuite/gas/ppc/xcoff-function-1-64.d: New test. * testsuite/gas/ppc/xcoff-function-1.s: New test. bfd * coff-rs6000.c (xcoff_dwsect_names): Add new DWARF sections. * coffgen.c (coff_pointerize_aux): Handle C_DWARF. (coff_print_symbol): Likewise. * libxcoff.h (XCOFF_DWSECT_NBR_NAMES): Update. gas * config/obj-coff.c (coff_frob_symbol): Don't skip C_DWARF. (coff_adjust_section_syms): Use corrext auxent for C_DWARF. (coff_frob_section): Likewise. * config/obj-coff.h (SA_GET_SECT_SCNLEN, SA_GET_SECT_NRELOC, SA_SET_SECT_SCNLEN, SA_SET_SECT_NRELOC) New defines. (SET_SECTION_RELOCS): Adjust for C_DWARF. * config/tc-ppc.c (ppc_frob_symbol): Don't skip C_DWARF. (ppc_adjust_symtab): Reorder C_DWARF symbols. * testsuite/gas/ppc/aix.exp: New tests. * testsuite/gas/ppc/xcoff-dwsect-2-32.d: New test. * testsuite/gas/ppc/xcoff-dwsect-2-64.d: New test. * testsuite/gas/ppc/xcoff-dwsect-2.s: New test. include * coff/internal.h (C_DWARF): New define. * coff/xcoff.h (SSUBTYP_DWLOC, SSUBTYP_DWFRAME, SSUBTYP_DWMAC): New defines.
2021-05-07x86: don't mix disp and imm processingJan Beulich1-1/+1
Surely disp processing should access the disp operand, not an imm one. This is not an active issue only because imms and disps are, at the moment, overlapping fields of the same union.
2021-05-07x86: move register check in immediate operand parsingJan Beulich1-7/+7
i386_finalize_immediate() is used for both AT&T and Intel immediate operand handling. Move an AT&T-only check to i386_immediate(), which at the same time allows it to cover other cases as well, giving an overall better / more consistent diagnostic.
2021-05-07x86: minor improvements to optimize_imm()Jan Beulich1-8/+6
- Drop a pointless & where just before it was checked that the respective bits are clear already anyway. - Avoid a not really necessary operand_type_set() and a redundant operand_type_or() / operand_type_and() pair.
generated by cgit v1.1 at 2025-02-12 13:47:27 +0000