aboutsummaryrefslogtreecommitdiff
path: root/gas
AgeCommit message (Collapse)AuthorFilesLines
46 hoursgas: testsuite: aarch64: Resolve duplicate testrun names.Richard Earnshaw3-3/+3
These are all simple typos in the test names.
46 hoursgas: testsuite: aarch64: Remove duplicate test from sv2p1-5.dRichard Earnshaw1-1/+0
This test runs with the assembler options '-march=armv9.4-a' twice. Looking at the related tests in this set, this appears to be redundant rather than a typo, so remove the second run.
47 hoursgas: Define comment_chars for non-ELF PowerPC targetsNick Clifton2-7/+7
2 daysgas: testsuite: all: Avoid clashing names in err-sizeof.sRichard Earnshaw1-1/+1
The first junk test in this file was missing "junk" in the test name, which resulted in a duplicate test name when comparing with the real test on line 3.
2 daysgas: testsuite: elf: avoid clashing mbind test namesRichard Earnshaw1-1/+1
The section12b.d test has the wrong name, leading to a clash with the section 16b.d test. Fix that up.
2 daysgas: testsuite: all: use unique test names for multibyte3 testsRichard Earnshaw1-1/+1
There are two tests of the mutibyte3 source file, with different options. As things stand this results in two distinct tests in the logs with the same name. Avoid this by adding the optional testname option to the second test.
2 daysRemove Solaris/PowerPC supportRainer Orth10-96/+32
Solaris/PowerPC was a shortlived Solaris port with limited hardware support. It was released with Solaris 2.5.1 back in 1996, with support removed again only a year later in Solaris 2.6. Since this is long obsolete, this patch removes the remains of the support. Tested by a cross to ppc-unknown-linux-gnu to ascertain the build didn't get broken. 2025-09-15 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> bfd: * config.bfd <powerpc-*-solaris2*>: Remove. gas: * NEWS: Mention Solaris/PowerPC removal. * configure.ac <ppc-*-solaris*>: Remove. * configure: Regenerate. * configure.in: Regenerate. * configure.tgt <ppc-*-solaris*>: Remove. * config/tc-ppc.c (ppc_solaris_comment_chars): Remove. (ppc_eabi_comment_chars): Remove. (SOLARIS_P): Remove. (msolaris): Remove. (md_parse_option): Remove "solaris", "no-solaris" hangling. (md_show_usage): Likewise. (md_begin): Remove msolaris handling. * config/tc-ppc.h (ppc_comment_chars): Fix declaration. * stabs.c (s_stab_generic) [TC_PPC && OBJ_ELF]: Remove 4-arg .stabd support. * doc/as.texi (Overview, Target PowerPC options): Remove -msolaris, -mno-solaris. * doc/c-ppc.texi (PowerPC-Opts): Remove -msolaris, -mno-solaris. (PowerPC-Chars): Remove ! as line comment character. ld: * configure.tgt <powerpc*-*-solaris*>: Remove.
2 daysgas/expr.h fixmeAlan Modra1-12/+4
* expr.h (expressionS): Adjust comments. Use ENUM_BITFIELD for X_op. (enum operatorT): Define.
2 daysDelete gas/po/gas.es.poAlan Modra1-24208/+0
es.po is newer, and this file is wrongly named.
3 daysarm: Rename some tests to avoid duplicate tests namesRichard Earnshaw29-29/+29
A number of arm-specific tests print the same name. This can cause problems if one of those tests fails, since then comparing tests with GCC's compare_tests script can result in ambiguities in the changes summary. Avoid this by giving tests unique names. Still to do is where a test is run more than once (eg by having multiple '#as: ' lines). This will require a tweak to the framework.
3 daysRISC-V: Add support for sdtrig and ssstrict extensions.Dongyan Chen4-0/+10
This implements the sdtrig extension, version 1.0[1] and ssstrict extension, version 1.0[2]. [1]https://github.com/riscv/riscv-debug-spec/blob/main/Sdtrig.adoc [2]https://github.com/riscv/riscv-profiles/issues/173 bfd/ChangeLog: * elfxx-riscv.c: Added sdtrig and ssstrict v1.0, and imply rules. gas/ChangeLog: * NEWS: Updated for sdtrig and ssstrict. * testsuite/gas/riscv/imply.d: DItto. * testsuite/gas/riscv/imply.s: Ditto. * testsuite/gas/riscv/march-help.l: Ditto.
6 daysRISC-V: Fixed more testcases for --with-arch and --with-abiNelson Chu4-0/+4
Same as cabae1c1c87d5f4ba28b7fdafe735b7c6207fb78
7 daystestsuite: RISC-V: Add '.option norvc' to ensure consistent results.Jiawei5-0/+5
Add `.option norvc` to several RISC-V tests to avoid compressed instruction generation. This ensures consistent disassembly and alignment behavior regardless of assembler default options. Discussion see: https://patchwork.sourceware.org/project/binutils/patch/20250910120916.1103023-1-jiawei@iscas.ac.cn/ gas/ChangeLog: * testsuite/gas/riscv/dis-partial-insn.s: Limit compressed. * testsuite/gas/riscv/no-relax-align.s: Ditto. * testsuite/gas/riscv/odd-padding.s: Ditto. * testsuite/gas/riscv/t_insns.s: Ditto. * testsuite/gas/riscv/tlsdesc.s: Ditto.
7 daysRISC-V: Remove ^M for odd-padding.s testcaseNelson Chu1-8/+8
8 daysgas: sframe: skip DW_CFA_GNU_args_size when safe to ignoreIndu Bhagat6-1/+119
Currently, gas warns and skips generating SFrame FDE when it sees: .cfi_escape 0x2e,XX From the documentation of DW_CFA_GNU_args_size: "The DW_CFA_GNU_args_size instruction takes an unsigned LEB128 operand representing an argument size. This instruction specifies the total of the size of the arguments which have been pushed onto the stack." With origins seemingly for VAX architecture, the usage of DW_CFA_GNU_args_size seems to have evolved. The purpose of DW_CFA_GNU_args_size is to adjust SP when performing stack unwinding for exception handling. For the purpose of stack tracing using SFrame, DW_CFA_GNU_args_size is safe to skip, especially when the CFA restoration is known to be FP based. A previous summary of the reasoning and intent was indicated here [1]. [1] https://sourceware.org/pipermail/binutils/2025-August/143829.html This fixes PR gas/33414 - sframe: handle DW_CFA_GNU_args_size in gas better gas/ PR gas/33414 * gen-sframe.c (sframe_xlate_do_escape_gnu_args_size): New definition. (sframe_xlate_do_cfi_escape): Handle DW_CFA_GNU_args_size. gas/testsuite/ PR gas/33414 * gas/cfi-sframe/cfi-sframe.exp: New test. * gas/cfi-sframe/cfi-sframe-common-12.d: New test. * gas/cfi-sframe/cfi-sframe-common-12.s: New test. * gas/cfi-sframe/cfi-sframe-x86_64-3.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-3.s: New test.
10 daysx86: constrain and fix use of the "nojumps" .arch modifierJan Beulich7-21/+84
As said by the paragraph of the description that isn't modified here (a few lines up), this was only ever supposed to be used with 16-bit architectures. Actually enforcing this allows code in md_estimate_size_before_relax() to move to a less frequently used code path. (For backwards compatibility, keep accepting "jumps" also with 32- or 64-bit architectures.) Repeat the constraint also in the 2nd paragraph of the doc on this subject. And while there also insert a missing insn in the related i386-Jumps section. Furthermore checking a global variable during late processing is wrong. We need to record the state in the fragment, and use that rather than the state of the variable at the end of parsing all input. Seeing that there's no testing of the functionality at all, add a testcase as well.
10 daysx86: make TC_FRAG_INIT() resolve to a function callJan Beulich2-37/+25
This way we can avoid making various global variables non-static. Their set is to only ever grow, really.
13 daysx86: check reloc types for relaxable branchesJan Beulich4-12/+26
Bypassing _reloc() isn't a good idea, as there are various errors checked for there. For example 16-bit JMP or Jcc may not use the @plt form (resulting in a 32-bit relocation to be emitted for a 16-bit field), which so far we only reject for 16-bit CALL. In exchange this allows simplifying the setting up of the "reloc_type" local variable.
13 daysx86: make reloc() usable during late phases of assemblyJan Beulich1-16/+33
Introduce a clone with extra parameters, to allow subsequent use from md_estimate_size_before_relax() (or elsewhere, should that turn out necessary). There flag_code cannot be used and location information needs to be provided for diagnostics.
2025-09-04RISC-V: Fixed missed GOT relocation against a symbol that has a defined valueNelson Chu3-37/+117
SImilar to aarch64, commit eac4eb8ecb26 There are two problems when GOT relocation against a symbol that has a defined value, 1. Pesudo la with pic and pseudo lga lost the relocations. 2. %got_pcrel_hi generates R_RISCV_GOT_HI20 with addend, which is wrong since commit 50331d64f108. The solution is to use deferred_expression for GOT relocation. Maybe other relocations also have same problem and need the deferred_expression, but we can add in the future patches.
2025-09-04mips: remove unnecessary obstack_finishAlan Modra1-1/+1
It isn't necessary to call obstack_finish before obstack_free of an unwanted string. * config/tc-mips.c (mips_parse_arguments): Replace obstack_finsih with obstack_base.
2025-09-03Disable eh_frame optimisation if code detected in .eh_frameAlan Modra4-32/+41
Fuzzers stress the assembler in ways no sane programmer would ever do. One x86 oss-fuzz testcase (cleaned up a litte) was: .sect .debug_frame call x .long x,0 .space 1 .long 0,0 The call insn leaves the frag data corresponding to a CIE uninitialised until later in assembly, leading to reports of uninitialised data access in ehopt.c:check_eh_frame. Hack around this problem by noticing an insn has been assembled in dwarf2_emit_insn. The existing frag has_code can't be used as that leads to alignment complaints, so add a new segment_info flag. * subsegs.h (struct segment_info_struct): Move bss and hadone later. Rename hadone to stab_seen. Add insn_seen bitfield. * dwarf2dbg.c (dwarf2_emit_insn): Set insn_seen. * ehopt.c (check_eh_frame): Disable optimisation if insn_seen. * stabs.c (s_stab_generic): Adjust for hadone rename.
2025-09-03frag_alloc use of obstack_allocAlan Modra1-8/+7
Avoid the alignment hackery necessary when obstack_alloc is used. obstack_alloc expands to obstack_blank plus obstack_finish, and the latter call is where alignment of the tail of the obstack happens. The docs say obstack_alloc "is invoked almost like malloc", which implies a fixed size allocation and you don't need other obstack calls in its use. So I think trying to use obstack_alloc in frag_alloc was always a poor choice. * frags.c (frag_alloc): Replace obstack_alloc with obstack_blank.
2025-09-03Explain frag alignment hacksAlan Modra2-11/+9
"the weird alignment hackery" comment doesn't help anyone understand the code. Explain what is going on. Replace the zero length obstack_alloc with obstack_finish, which by inspection of obstack.h is all the zero length alloc does. * frags.c (frag_alloc): Comment. Replace zero length obstack_alloc with obstack_finish. (frag_new): Remove unnecessary obstack_finish. * write.c (compress_frag, compress_debug): Likewise.
2025-09-03make frag fr_type a bitfieldAlan Modra1-1/+1
For better packing of struct frag. * frags.h (struct frag <fr_type>): Use ENUM_BITFIELD.
2025-09-03tidy tilegx and tilepro MAX_MEM_FOR_RS_ALIGN_CODEAlan Modra2-2/+4
These weren't wrong, but should use the BUNDLE_SIZE macros, in case they ever change. * config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use TILEGX_BUNDLE_SIZE_IN_BYTES. * config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use TILEPRO_BUNDLE_SIZE_IN_BYTES.
2025-09-03visium MAX_MEM_FOR_RS_ALIGN_CODEAlan Modra1-1/+1
Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for the "fix" amount emitted by visium_handle_align. This didn't show up as a problem due to frag alignment hiding the error, until I started messing with struct frag. * config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Correct.
2025-09-02PowerPC: Vector Instructions for Deeply Compressed Weight for AI (RFC02691)Abhay Kandpal2-0/+24
opcodes/ * ppc-opc.c: (VXSEL5, VXSEL4, VXSEL3, VXSEL2, UIMM1): New defines. (powerpc_opcodes): <vucmprhn, vucmprln, vucmprhb, vucmprlb, vucmprhh, vucmprlh, vupkhsntob, vupklsntob, vupkint4tobf16, vupkint8tobf16, vupkint4tofp32, vupkint8tofp32>: New instructions. gas/ * gas/testsuite/gas/ppc/future.s: Add new testcases. * gas/testsuite/gas/ppc/future.d: Likewise.
2025-09-02arm: rework fix for PR gas/15273Richard Earnshaw2-7/+7
PR gas/15273 The apparent intent of the original code added in https://sourceware.org/pipermail/binutils/2012-August/078044.html was to emit an error message if the instruction was obsolete and only to emit a deprecation warning if an error hadn't already been emitted. However, when the insn has not yet been obsoleted, the code would generate a warning with a (null) message body if the selected CPU was 'any'. The previous fix for this bug was to remove the support for the obsoletion message entirely, which was probably the wrong approach. A better fix is to only call check_obsolete if obs_msg is non-null; we can use this as a proxy for the instruction not being obsolete on any architecture. While we are here, fix an incorrect capitalization in the deprecation message ('This' to 'this').
2025-09-02x86/testsuite: Adjust unused FRED and MOVRS tests [PR33348]Haochen Jiang5-37/+2
The tests mentioned in PR33348 needs different care. For FRED tests, we could simply remove them since there are no operands and the tests are the same as AT&T Syntax. For MOVRS tests, we allowed suffixes for AT&T suffixes although we could tell the difference according to register operand to align with legacy mov. Thus, the suffixes tests are needed for AT&T Syntax while not needed for Intel Syntax. Adjust them accordingly. gas/ChangeLog: PR ld/33348 * testsuite/gas/i386/x86-64-movrs-suffix.d: Describe the test with more precise. * testsuite/gas/i386/x86-64-movrs-suffix.s: Remove Intel Syntax part. * testsuite/gas/i386/x86-64.exp: Add MOVRS suffix tests. * testsuite/gas/i386/x86-64-fred-intel.d: Removed. * testsuite/gas/i386/x86-64-movrs-suffix-intel.d: Ditto.
2025-09-02LoongArch: Fix incorrect display of FDEs address ranges when using objdump -WfLulu Cai3-1/+43
When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to help `objdump` correctly compute the address ranges of the FDEs. Apply the same modification to BFD_RELOC_LARCH_64_PCREL.
2025-08-29x86: add "udb" opcode (permanent official #UD in 64-bit mode)H. Peter Anvin (Intel)2-0/+2
The opcode D6 has been officially reserved as a single-byte permanent undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is already the behavior of all known 64-bit implementations; this is thus merely an official statement of forward compatibility and the assignment of a mnemonic. This will be documented in the next version of the Intel Software Developer's Manual; in the meantime I DO speak officially for Intel on this issue. The x86 Advisory Council has ratified this decision, and so it is expected to be honored across vendors, but I obviously cannot make any official statement on any other vendor's behalf. I am covered by the Intel-FSF copyright assignment for binutils. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2025-08-25PR 33302, Symbols truncated on i386pep targetAlan Modra3-1/+7
Commit 012d44268695 effectively made peXXigen.c _bfd_XXi_swap_aux_out always use the COFF E_FILNMLEN of 14. The problem was that the auxent x_fname field was defined in include/coff/external.h using a length of 14. Later, E_FILNMLEN is redefined to 18 in coff/pe.h. This no doubt falsely tripped memory checking tools. AUXESZ is 18, so no actual buffer overrun. This patch defines x_fname as an 18 char field, the full auxent, and uses E_FILNMLEN when accessing. PR 33302 include/ * coff/external.h (union external_auxent): Make x_fname AUXESZ chars. bfd/ * coffswap.h (coff_swap_aux_in): Correct #error message. (coff_swap_aux_out): Likewise. Use E_FILNMLEN when copying to ext field. * peXXigen.c (_bfd_XXi_swap_aux_in): Add #error. Style fix. (_bfd_XXi_swap_aux_out): Add #error. Don't use sizeof, use E_FILNMLEN when copying to ext field. gas * testsuite/gas/pe/long_file_symbol.d, * testsuite/gas/pe/long_file_symbol.s: New test. * testsuite/gas/pe/pe.exp: Run it. Reported-By: Frediano Ziglio <freddy77@gmail.com>
2025-08-23gas: add --enable-default-sframe configure optionSam James7-5/+65
SFrames make the most sense when userland as a whole is built with them, so add a --enable-default-sframe configure flag to facilitate distributors and vendors doing that. The primary motivation for a configure-time flag is that we don't support SFrame for 32-bit x86 but some packaging uses the same flags (with some added on top) for multilib builds (to support old binaries like games), and simply adding `-Wa,--gsframe` to the standard build flags isn't an option (*). That aside, I believe it'll be helpful for testing and eventual adoption in any case. In summary, combined with the recent --gsframe=[yes|no] support (**): * Configured with --enable-default-sframe and nothing is passed => SFrames (previously no SFrames) * Configured with --enable-default-sframe and --gsframe=yes is passed => SFrames (no change from before) * Configured with --enable-default-sframe and --gsframe=no is passed => No SFrames (no change from before) * Configured with --enable-default-sframe and --gsframe is passed => SFrames (no change from before) * Configured with --disable-default-sframe and nothing is passed => No SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe=yes is passed => SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe=no is passed => No SFrames (no change from before) * Configured with --disable-default-sframe and --gsframe is passed => SFrames (no change from before) I've introduced a sframe_as_bad macro on Indu's suggestion. A following patch uses its sibling sframe_as_warn heavily and having symmetry plus the macro as a form of documentation of intent seems useful. (*) It gets added to multilib builds too and then we hit the `.sframe not supported for target` error in gas/dw2gencfi.c. (**) I've verbosely listed --gsframe=yes but it's the same as --gsframe. gas/ PR gas/33126 * as.c (enum gen_sframe_option): Initialize if DEFAULT_SFRAME. * config.in (DEFAULT_SFRAME): New. * configure: Regenerate. * configure.ac: Add --enable-default-sframe. * doc/as.texi: Document --enable-default-sframe. * dw2gencfi.c (cfi_finish): Don't warn if SFrames are enabled by default but unavailable for this target. * gen-sframe.h (sframe_as_bad): New macro.
2025-08-22gas: make as_tsktsk() output more as_warn()-likeJan Beulich17-154/+145
The lack of a uniform "Warning: " prefix can be irritating. Re-use as_warn_internal(), by moving the warning count increment into the pre- existing callers (where the flag_no_warnings checks also are). At the same time keep the listing_warning() invocation at its place - listings certainly should have such warnings reproduced as well. While there also drop the unnecessary forward declarations of static functions.
2025-08-22Don't run cfi-commit-10 test on 32-bit targetsAlan Modra1-1/+3
2025-08-20RISC-V: PR33216, Fixed gcc testcases failed for commit 28520d7Nelson Chu2-7/+14
I made a stupid mistake in the commit 28520d7, allow to assemble slli/srli/srai with 0 immediate to hint c.slli/c.srli/c.srai. These hints will be regared as illegal instruction for gdb and qemu, so at least I got following gcc testcases failed, === g++: Unexpected fails for rv64gc lp64d medlow === FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test === gfortran: Unexpected fails for rv64gc lp64d medlow === FAIL: gfortran.dg/leadz_trailz_2.f90 -O0 execution test === gcc: Unexpected fails for rv64gc lp64d medlow === FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test So we should just allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate. gas/ PR 33216 * testsuite/gas/riscv/c-zero-imm.d: Only allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate. * testsuite/gas/riscv/c-zero-imm.s: Likewise. opcodes/ PR 33216 * riscv-opc.c (match_slli_as_c_slli): Added back. (match_srxi_as_c_srxi): Likewise. (riscv_opcodes): Only allow c.slli/c.srli/c.srai with zero immediate as hints, but don't allow slli/srli/srai with zero immediate.
2025-08-20Remove cloudabi supportAlan Modra5-34/+1
Apparently the cloudabi project is dead. The cloudabi support branded object files with ELFOSABI_CLOUDABI but other than that didn't do much.
2025-08-20Re: gas: testsuite: fix regression in cfi-common-10.dAlan Modra1-13/+2
Just match what the test is actually trying to verify, to fix more regressions.
2025-08-19gas: testsuite: fix regression in cfi-common-10.dIndu Bhagat1-2/+2
A previous commit 09292f4ae2c introduced the new test cfi-common-10.d. The testcase needs some adjustments for it to be useful on a variety of targets.
2025-08-19binutils: dwarf: fix display of large cfa_offsetIndu Bhagat5-0/+45
eh_frame textual dump was not correct when the cfa_offset is a large value. The reason is that the dumping code generally assumes the cfa_offset is an 'int'. cfa_offset values can be updated by various DWARF opcodes, like: - DW_CFA_def_cfa, DW_CFA_def_cfa_offset which bring unsigned leb128 cfa_offset - DW_CFA_def_cfa_sf, DW_CFA_def_cfa_offset_sf which bring signed leb128 cfa_offset Internally, the routines in dwarf.c keep the value as 'uint64_t cfa_offset'. That size of the datatype is expected to work for most of the real-world cases. Care, however, needs to be taken when it comes to the signedness of the value. Fix the buggy behavior by adding an additional field to track whether the value of cfa_offset is signed or unsigned and display accordingly for "frames-interp" output. The display of cfa_offset had issues in both "frames-interp" output (objdump -WF or do_debug_frames_interp) and the "frames" output. Add two new tests: cfi-common-10.s uses a large positive cfa_offset (with "frames output), and cfi-x86_64-2.s uses a negative cfa_offset (with "frames-interp" output). ChangeLog: * binutils/dwarf.c (frame_display_row): Update format string based on signedness. (display_debug_frames): Track signedness. Also fix display of cfa_offset using PRIu64 or PRId64 as applicable. * gas/testsuite/gas/cfi/cfi.exp: Add two new tests. * gas/testsuite/gas/cfi/cfi-common-10.d: New test. * gas/testsuite/gas/cfi/cfi-common-10.s: New test. * gas/testsuite/gas/cfi/cfi-x86_64-2.d: New test. * gas/testsuite/gas/cfi/cfi-x86_64-2.s: New test.
2025-08-18gas: Record file name in macro locationsAlice Carlotti3-11/+13
This allows the correct file name to be used when emitting messages for lines within a macro. The line numbers were already set and displayed correctly, which resulted in mismatched file names and line numbers. PR 32738
2025-08-18gas: Improve file name in messages headerAlice Carlotti7-13/+33
Message output from gas is prefixed with a line of the form: path/file.s: Assembler messages: Don't use the file name from the first message for this header. Instead, use the source file name specified in the command line.
2025-08-15gas: sframe: const ptrs for args and local vars where applicableIndu Bhagat1-23/+23
Use const pointers for function arguments and local vars where applicable. 'cfi_insn' contains the DWARF CFI instruction data which, for the purpose of SFrame generation, is read-only. Similarly, some getter APIs and output related APIs now document their argument as read-only. While at it, also remove the ATTRIBUTE_UNUSED from argument xlate_ctx in sframe_xlate_do_register () because the argument is indeed conditionally used.
2025-08-15x86/APX: drop AMX-TRANSPOSE promoted insnsJan Beulich5-68/+2
They were dropped from spec version 007.
2025-08-15gas/ELF: allow specifying entity size for arbitrary sectionsJan Beulich6-22/+64
The spec doesn't tie entity size to just SHF_MERGE and SHF_STRINGS sections. Introduce a new "section letter" 'E' to allow recording (and checking) of entity size even without 'M' or 'S'.
2025-08-15gas/ELF: adjust bad section letter diagnosticJan Beulich3-4/+7
Being told of a problem with .section when .pushsection was used can be irritating, especially when several of them are on the same line.
2025-08-15gas/ELF: re-work SHF_GNU_* handlingJan Beulich7-54/+55
Indicate to obj_elf_parse_section_letters() whether to recognize GNU- specific flags by conditionally passing NULL in place of a pointer to the GNU attributes. This way wrong use of d and R can be diagnosed just like any other use of unrecognized letters. Furthermore adjust the md_elf_section_letter() interface: Have targets merely return the extra letters they support. There's no point having them customize the entire diagnostic. Even more so that additions in common code would then reflecting in every target's diagnostic as well, which - as can be seen - wasn't always properly done. There's also no reason for wrong letters to be a fatal error; switch to as_bad() while making other adjustments there. While making the target specific adjustments, also drop IA-64's dead handling of 'o' (SHF_LINK_ORDER), which has been covered by common code for a long time. Also re-arrange the switch() in obj_elf_parse_section_letters() to be alphabetically sorted again.
2025-08-15gas/ELF: drop bogus check for ELFOSABI_STANDALONEJan Beulich5-13/+3
obj_elf_parse_section_letters() checking for that ABI, when the checking at the bottom of obj_elf_section() and the logic in _bfd_elf_final_write_processing() don't, makes no sense. Either STANDALONE is meant to be GNU-ish, or it is not, I would think. Drop the one inconsistent check. If it was not GNU-ish (as the other two locations suggest), what did the section23b testcase actually mean to check? The numeric attribute value 0x200000 has an entirely unknown (or more precisely, OS-defined, which we may or may not know of) meaning then, so ought to be accepted. If it was GNU-ish, the other testcase, elf/section23a, would want running for those targets as well, and the testcase in question would still be wrong to have. Hence that testcase is removed, and section23a is renamed to just section23.
2025-08-14RISC-V: PR33216, Allow c.slli, c.srai, c.srli with 0 immediate as a hintNelson Chu3-8/+8
The original patch, e6f372ba661bb0d8eec1e22a6dc1ad9937336e4d Since recently c.slli64, c.srai64, and c.srli64 have been removed from the riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed as hints, https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093 So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with 0 immediate. Passed rv32/64-elf/linux binutils testcases. gas/ PR 33216 * testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64, c.srai64, and c.srli64 with 0 immediate as a hint. * testsuite/gas/riscv/c-zero-imm.s: Likewise. * testsuite/gas/riscv/zca.d: Likewise. opcodes/ PR 33216 * riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64, and c.srli64 with 0 immediate as a hint.
generated by cgit v1.1 at 2025-09-18 13:05:54 +0000