aboutsummaryrefslogtreecommitdiff
path: root/gas
AgeCommit message (Collapse)AuthorFilesLines
2025-05-22ubsan: integer overflow in tc-i386.c:offset_in_rangeAlan Modra1-1/+1
or $9223372036854775808,%eax runtime error: negation of -9223372036854775808 cannot be represented in type 'offsetT' (aka 'long'); cast to an unsigned type to negate this value to itself * config/tc-i386.c (offset_in_range): Avoid signed overflow.
2025-05-19ubsan: integer overflow in s_fillAlan Modra1-4/+4
Silence ubsan warning. We don't worry about wrap-around in most places that adjust abs_section_offset, so don't fuss over an overflow in the multiplication here. * read.c (s_fill): Replace "long" vars with offsetT and valueT. Avoid signed overflow calculating abs_section_offset.
2025-05-19RISC-V: Add implication from the XTheadZvamo extensionTsukasa OI2-0/+2
T-Head/XuanTie's vector extension documentation states that their vector extensions are based on the standard vector extension draft, version 0.7.1. In that draft, it is rare to see dependencies between extensions as in the ratified version ... except: "Zvamo" -> "Zaamo". cf. <https://github.com/riscvarchive/riscv-v-spec/releases/tag/0.7.1> > If vector AMO instructions are supported, then the scalar Zaamo > instructions (atomic operations from the standard A extension) > must be present. Note that using the words like "imply" or "depend" for extensions weren't a common practice to represent dependencies between extensions at the time the documentation was created. The "Zaamo" was not ratified as an extension at the time but this is a subset of the "A" extension and defines scalar AMO operations (while "Zvamo" -- NOT in the ratified specification -- defines vector AMO ops). The important part is that the T-Head/XuanTie's documentation just states that the "Zvamo" (draft) extension is renamed to "XTheadZvamo". It means, this implication should have been preserved in some way. > The extension Zvamo is renamed to XTheadZvamo. cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc> bfd/ChangeLog: * elfxx-riscv.c (riscv_implicit_subsets): Add implication "XTheadZvamo" -> "Zaamo". gas/ChangeLog: * testsuite/gas/riscv/imply.s: Add "XTheadZvamo" implication. * testsuite/gas/riscv/imply.d: Ditto.
2025-05-19RISC-V: Add implicit dependency to the XTheadVector extensionTsukasa OI2-0/+3
While this dependency is not directly stated in the documentation, the XTheadVector extension cannot work without the Zicsr extension (the documentation does not specify CSR access instruction subset either as in the Zkr extension or the seed CSR section in the manual). Also, making an implication to the Zicsr extension is in parity with the ratified vector extensions (in GNU Binutils, the Zve32x extension -- a dependency of V -- depends on the Zvl32b and Zicsr extensions). This commit adds this implicit dependency. bfd/ChangeLog: * elfxx-riscv.c (riscv_implicit_subsets): Add implicit dependency "XTheadVector" -> "Zicsr". gas/ChangeLog: * testsuite/gas/riscv/imply.s: Add implicit "XTheadVector" dependency to the "Zicsr" extension. * testsuite/gas/riscv/imply.d: Ditto.
2025-05-19RISC-V: Wider conflicts with the XTheadVector extensionTsukasa OI2-2/+2
T-Head/XuanTie's "XTheadVector" is based on a draft version of the now standard vector extensions and it conflicts with not just the "V" extension but all of its subsets. This commit makes "XTheadVector" conflict with the "Zve32x" extension, which is the smallest subset of the standard vector extensions. Still, a reference to "V" is preserved in the error message as the documentation suggests: > Therefore, the XTheadVector extension and the V extension are > in conflict. cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc> Note that, instructions in the "XTHeadZvamo" extension currently has no conflicts with other extensions, even after addition of the "Zabha" extension. bfd/ChangeLog: * elfxx-riscv.c (riscv_parse_check_conflicts): Make "XTheadVector" conflict with not just "V" but its subsets. gas/ChangeLog: * testsuite/gas/riscv/x-thead-vector-fail.d: Test a vector subset "Zve32x" to test failures. * testsuite/gas/riscv/x-thead-vector-fail.l: Reflect change in the error message.
2025-05-19gas: sframe: handle .cfi_undefinedIndu Bhagat6-0/+87
Fix PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas In context of SFrame generation, it is incorrect to simply ignore all .cfi_undefined. We may ignore only those .cfi_undefined which are for registers of no interest (similar to whats done for other CFI directives). gas/ * gen-sframe.c (sframe_xlate_do_cfi_undefined): New definition. (sframe_do_cfi_insn): Handle .cfi_undefined. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: Add new tests. * gas/cfi-sframe/cfi-sframe-common-10.d: New test. * gas/cfi-sframe/cfi-sframe-common-10.s: New test. * gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: New test. * gas/cfi-sframe/cfi-sframe-x86_64-empty-4.s: New test.
2025-05-19gas: sframe: reword diagnostic to address ambiguityIndu Bhagat8-20/+21
The current warning text of "skipping SFrame FDE" does not unabiguously indicate that the SFrame FDE is not generated in the output section. Reword the diagnostic to say "no SFrame FDE emitted" as requested. Adjust the testcases for the updated warning.
2025-05-19gas: sframe: i386: have the backend specify the RA tooIndu Bhagat3-43/+18
To process some CFI directives like .cfi_undefined and .cfi_same_value, it is necessary for correctness to detect all cases when the register used is one of SP, FP or RA. Currently, the backends needed to specify the SFRAME_CFA_RA_REG only in the case of those ABIs where RA tracking was necessary, e.g. AArch64. For AMD64, since the return address is always at a fixed offset from the CFA, RA tracking was disabled. The backends must now specify the applicable return address register via SFRAME_CFA_RA_REG. This is necessary so that SFrame generation code can then properly handle the cases when RA is used like so: .cfi_undefined <RA> or, .cfi_same_value <RA> Detecting these cases is necessary for correctness. E.g., on AMD64, we need to skip FDE generation as the above constructs cannot be represented in SFrame yet. This change is a prerequisite to fixing the two PRs: PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas In the SFrame generation code in gen-sframe.c, instead of using SFRAME_FRE_RA_TRACKING ifdef's, we now simply rely on the API sframe_ra_tracking_p () to detect if RA-tracking is enabled for the target. While at it, use const variables for x86 backend. ChangeLog: * gas/config/tc-i386.c (x86_sframe_cfa_ra_reg): New definition. * gas/config/tc-i386.h (REG_RA): New definition. (SFRAME_CFA_RA_REG): New declaration. * gas/gen-sframe.c (SFRAME_FRE_RA_TRACKING): Remove.
2025-05-16ubsan: emit_inc_line_addr integer overflowAlan Modra1-1/+1
Commit 07cf922195d1 fixed the one in size_inc_line_addr. Silly me missed the identical overflow in emit_inc_line_addr
2025-05-16gas .align limitAlan Modra1-5/+11
At the moment we allow alignment of up to half the address space, which is stupidly large and results in OOM on x86_64. Change that to 1G alignment in text sections. Also fix the warning message on exceeding max allowed alignment. * read.c (TC_ALIGN_LIMIT): Limit to 30 in text sections. (s_align): Correct "alignment too large" value.
2025-05-16gas: adjust a comparison in s_align()Jan Beulich1-1/+1
In 344b1e0f5f79 ("gas: range-check 3rd argument of .align et al") I neglected to consider compilers which warn about signed/unsigned mismatches in comparisons (which is somewhat odd when the signed value is already known to be non-negative).
2025-05-16gas: range-check 3rd argument of .align et alJan Beulich1-1/+7
Negative values would have been silently converted to large positive ones, which may not be the user's intention. Similarly overly large values would have been silently truncated. Warn them instead, and zap such values.
2025-05-16x86: improve matching diagnostics when %st is involvedJan Beulich3-18/+52
Diagnosing operand size vs operand type mismatches doesn't work very well when GPRs and FPRs are in the same register class, distinguished just by size. Introduce a separate RegFP class.
2025-05-16x86: move Anysize check in operand_size_match()Jan Beulich1-5/+1
Anysize is applicable to memory operands only. Move the check to where memory operands are handled. (The RegSIMD part there was questionable altogether.)
2025-05-16x86: improve matching diagnostics when "accumulator" registers are involvedJan Beulich3-3/+40
In templates, the expectation of an "accumulator" register to be used is expressed solely by operand size; there's no "class" specifier there. Hence operand_size_match() is too eager in invoking match_{operand,simd}_size(), resulting in "operand size mismatch" errors when it's the type (of register), not the size that's wrong. Interestingly adjustments there alone lead to no error at all then: To "compensate", operand_type_match() needs to disambiguate register types when register instances are specified in the template (matching the actual operand), by checking a match (overlap) in operand sizes.
2025-05-16x86: fold Accum checking in operand_size_match()Jan Beulich1-16/+13
There's little point invoking match_{operand,simd}_size() twice per loop; in fact the SIMD case with D set simply doesn't exist. Amend the checks by one looking at the given operand, just like we already have been doing for memory ones.
2025-05-16x86: improve matching diagnosticsJan Beulich6-7/+31
Many times in the past I was puzzled by seeing "operand size mismatch" when really "operand type mismatch" would be far more appropriate. As it turns out, there were at least two flaws: In the single operand case we didn't propagate i.error to match_template()'s local specific_error when noticing a type mismatch. And then operand_size_match() was too eager in invoking match_mem_size(): Especially the Unspecified attribute can get in the way there when the expected operand isn't a memory one (and hence Unspecified would not be set in the operand template, whereas it's uniformly set for memory operands in AT&T syntax). (In the x86-64-lkgs-inval testcase the particular error for the two bogus Intel syntax forms doesn't really matter; all we ought to care about there isthat there is _some_ error.)
2025-05-16x86: drop bogus accumulator checkJan Beulich1-1/+0
Accum is an "instance", not a "class". With present enumerator values of Reg and Accum, the 2nd check simply did the same as the first. In fact checking for the accumulator (%rax) isn't necessary here at all, because there's no case where an individual template would permit alternatively a memory operand or the (qword) accumulator; only "any GPR" is ever being paired with "memory".
2025-05-16RISC-V: check offsets when linker relaxation is disabledTsukasa OI12-6/+214
The assembler partially relied on the linker to check whether the offset is valid. However, some optimization logic (added later) removes relocations relative to local symbols without checking offsets. For instance, it caused following code to silently emit wrong jumps (to the jump instruction "." itself) without relocations: > .option norelax > j .+0x200000 # J (or JAL) instruction cannot encode this offset. > j .+1 # Jump to odd address is not valid. This commit adds offset checks where necessary. gas/ChangeLog: * config/tc-riscv.c (md_apply_fix): Check offsets when the relocation relative to a local symbol is being optimized out. * testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure case where the branch offset is invalid. * testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto. * testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto. * testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case. * testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto. * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure case only on RV64 where the PC-relative offset exceed limits. * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto. * testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto. * testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test case for RV32 so that no errors occur. * testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case. * testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto.
2025-05-16RISC-V: Add zilsd & zclsd supportdysun9-1/+140
Ref: https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc Signed-off-by: dysun <sundongya@nucleisys.com> Co-developed-by: LIU Xu <liuxu@nucleisys.com> Co-developed-by: ZHAO Fujin <zhaofujin@nucleisys.com>
2025-05-15gas: sframe: avoid creating more symbols than necessary for FRE offsetIndu Bhagat1-10/+10
Each SFrame FDE contains an offset to the start of its respective SFrame FREs in the sfde_func_start_fre_off field. To generate this offset, fre_symbols[] array is being used. The number of elements of this array is currently set to the total number of SFrame FREs in the entire SFrame section. This is more than unnecessary. We only need to track as many points as the number of SFrame FDEs. gas/ * gen-sframe.c (output_sframe_internal): Size fde_fre_symbols with the number of SFrame FDEs.
2025-05-15gas .file 0 vs. dwarf5Alan Modra1-3/+2
Support added in commit 3417bfca676f for dwarf5 directory table 0 assumed that .file 0 was always the first debug .file directive. That's not necessarily true. * dwarf2dbg.c (get_directory_table_entry): Don't assume entry 1 is available after putting DW_AT_comp_dir in entry 0. Pass pwd as file0_dirname to recursive call to avoid another getpwd in the case file0_dirname is NULL.
2025-05-14gas .file sanity checkAlan Modra1-19/+11
Currently we allow insane file numbers that cause gas to allocate up to 4G of memory for a file array. Trim that a little to 1G (which still allows insane file numbers up to 33554431), and tidy function parameter types so that we only need one file number sanity check. * dwarf2dbg.c (assign_file_to_slot): Take a valueT file number. Reduce max files array size. (allocate_filename_to_slot): Take a valueT file number. (dwarf2_directive_filename): Don't duplicate file number sanity check here.
2025-05-14Remove annoying space from gas/config/obj-elf.cMatthieu Longo1-1/+1
2025-05-12aarch64: Support for FEAT_RME_GPC3Ezra Sitorus2-0/+18
FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces a method for defining a set of windows in the memory map for which Granule Protection Checks are skipped, and instead applies a set of default settings associated with the window. This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to access this sysreg since this feature is optional from armv9.5-a.
2025-05-12aarch64: Support for FEAT_OCCMOEzra Sitorus2-0/+26
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces system instructions that provides software with a mechanism to publish writes to the Outer cache level.
2025-05-11ubsan: size_inc_line_addr integer overflowAlan Modra1-1/+1
Fix a fuzzer testcase where a large positive line_delta causes signed overflow when subtracting -5. Signed overflow is perfectly OK here.
2025-05-11msan: use of uninitialised data in get_cie_infoAlan Modra1-19/+28
This completely bogus oss-fuzz x86 testcase results in a read from an uninitialised (at the time check_eh_frame is called) part of an insn frag: .section .debug_frame orl $1,x .long x .uleb128 0,x,0 x: Fix the problem by verifying the assumption in get_cie_info that a CIE starts at the beginning of .eh_frame or .debug_frame. Or at least exclude silliness involving instructions placed there. That seems a useful sanity check. Also sanity check sizes of initial FDE fields. Yes, this doesn't completely stop the problem since you could place an insn with a relocated field later in the CIE. If fuzzers find such a testcase I'll ignore it. * ehopt.c (struct cie_info): Add "f" field. (get_cie_info): Return a bool. Verify frag at start of chain is one with the CIE size found by check_eh_frame. (check_eh_frame): Save CIE start frag. Only accept 4 or 8 byte fields in state_saw_size, state_saw_cie_offset and state_saw_pc_begin. Formatting. Localise "fix" variable.
2025-05-09aarch64: Merge dgh tests into system.dAlice Carlotti4-15/+2
2025-05-09aarch64: Fix dgh disassemblyAlice Carlotti2-3/+3
2025-05-09aarch64: Add new test original-missing-misc.dAlice Carlotti2-0/+88
This test file includes all the remaining untested instructions that weren't part of a larger group of new or existing tests.
2025-05-09aarch64: Add new test mov-wide.dAlice Carlotti2-0/+86
Only movn was previously untested.
2025-05-09aarch64: Add new test exception-generation.dAlice Carlotti2-0/+54
svc and dcps* were already tested, but are included here as part of the same encoding group.
2025-05-09aarch64: Add new test conditional-compare.dAlice Carlotti2-0/+153
The register form of ccmp was already tested.
2025-05-09aarch64: Add new test branch-cond-pseudos.dAlice Carlotti2-0/+73
beq, bne, bcs and bcc were already tested, and bge and ble are also used in scfi tests.
2025-05-09aarch64: Add new test ldst-unpriv.dAlice Carlotti2-0/+125
All instructions were previously untested.
2025-05-09aarch64: Add new test ldst-extend-general.dAlice Carlotti2-0/+307
All instructions were previously untested.
2025-05-09aarch64: Add new test dp-general-two-source.dAlice Carlotti2-0/+178
lsl was already tested but is included here as part of the same encoding group.
2025-05-09aarch64: Add new test dp-general-one-source.dAlice Carlotti2-0/+88
rev16 and the 64-bit rev/rev64 instructions were already tested, but are included here as part of the same encoding group.
2025-05-09aarch64: Add new test addsub-carry.dAlice Carlotti2-0/+102
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-scalar-doubling-mul.dAlice Carlotti2-0/+194
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-scalar-two-reg-misc.dAlice Carlotti2-0/+221
sqabs, sqneg, abs and neg were already tested, but are included here as part of the same encoding group.
2025-05-09aarch64: Add new test advsimd-scalar-shift-immediate.dAlice Carlotti2-0/+356
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-scalar-three-same.dAlice Carlotti2-0/+414
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-copy.dAlice Carlotti2-0/+359
Only smov and the second dup variant were previously untested. However, the only test for umov was a disassembly test with -M no-aliases, and the first dup variant was only tested in assembly in diagnostic.d with the non-architectural syntax `dup v0.2d, v1.2d[0]`.
2025-05-09aarch64: Add new test advsimd-permute.dAlice Carlotti2-0/+501
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-modified-immediate.dAlice Carlotti2-0/+201
All instructions (7 opcode table entries) were previously untested.
2025-05-09aarch64: Add new test advsimd-two-reg-misc-hilo.dAlice Carlotti4-0/+1454
All instructions were previously untested.
2025-05-09aarch64: Add new test advsimd-two-reg-misc.dAlice Carlotti2-0/+830
sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was already assembled in an error test (sve-reg-diagnostic.d), but they are all included here as part of the same encoding group.
2025-05-09aarch64: Add new test advsimd-mul-element.dAlice Carlotti2-0/+750
All instructions were previously untested.
generated by cgit v1.1 at 2025-09-19 05:44:42 +0000