Generic Interrupt Controller v5, GICv5, adds new system registers
and system instructions. These are enabled with the +gcie flag, where
gcie stands for GICv5 (Generic Interrupt Controller) CPU Interrupt
Extension.
There is a make_expr_symbol in append_insn, which gets called from
macro_build, which is all over the place. Many of these set up an
expression without initialising all fields. Now the uninitialised
fields should not be accessed in a properly functioning assembler,
but I'm inclined to think anything copied ought to be initialised.
* config/tc-mips.c (fix_loongson2f_jump, load_register),
(add_got_offset, add_got_offset_hilo, macro_build_branch_likely),
(macro, mips16_macro, s_cpload, s_cpsetup, s_cprestore)
(s_cpreturn): Use structure initialiser to ensure all fields of
expression are initialised.
(load_address): Copy entire structure for the same reason.
There are many more places that copy an uninitialised expressionS to a
symbol via symbol_set_value_expression and make_expr_symbol. This
patch focuses on general gas code that does that, and a few backends.
Note that unlike the i386 case that oss-fuzz found, it is likely that
the tc-alpha.c, tc-ppc.c and tc-tic54x.c changes are not fixing bugs,
alpha and tic54x because they don't use X_md, ppc because it carefully
handles X_md. Also, as an example an O_constant expression should
only ever have its X_add_number field accessed, therefore the other
fields can stay uninitialised. However, I think that copying
uninitialised struct fields around is not good practice. If nothing
else it can be confusing when examining symbols under gdb.
I also replaced gen-sframe.c "#ifdef SFRAME_FRE_TYPE_SELECTION_OPT"
with "if (SFRAME_FRE_TYPE_SELECTION_OPT)" so code in the false
branches is compiled and thus less likely to bitrot. (As far as I can
see, SFRAME_FRE_TYPE_SELECTION_OPT is always 1.)
* cgen.c (expr_build_binary): Use structure initialiser to
ensure all fields of expression are initialised.
* config/obj-coff.c (obj_coff_val): Likewise.
* config/tc-alpha.c (add_to_link_pool): Likewise.
* config/tc-i386-intel.c (i386_intel_simplify): Likewise.
* config/tc-mips.c (fix_loongson2f_jump, load_register),
(load_address, add_got_offset, add_got_offset_hilo),
(macro_build_branch_likely, macro, mips16_macro),
(s_cpload, s_cpsetup, s_cprestore, s_cpreturn): Likewise.
* config/tc-ppc.c (ppc_function): Likewise.
* config/tc-tic54x.c (tic54x_field): Likewise.
* dw2gencfi.c (output_cfi_insn): Likewise.
* expr.c (expr_build_uconstant): Likewise.
* read.c (s_mri_common): Likewise.
* gen-sframe.c (create_fre_start_addr_exp),
(create_func_info_exp, output_sframe_row_entry): Likewise.
Don't conditionally compile via SFRAME_FRE_TYPE_SELECTION_OPT.
* cgen.c (gas_cgen_parse_operand): Use md_expr_init_rest.
* config/tc-microblaze.c (microblaze_s_weakext): Likewise.
* ecoff.c (ecoff_directive_weakext, ecoff_stab): Likewise.
* read.c (pseudo_set): Likewise.
This patch removes clean_up_expression which runs just before operand()
returns. clean_up_expression sets as yet uninitialised fields of
expressionS. Well, it sets fields based on the value of X_op,
trusting that others have been written, and has one notable exception:
X_md is not initialised.
Instead initialise expressionS fully inside operand(), which is called
at the start of expr(), and introduce md_expr_init for the odd
backends that want to mess with X_md.
This is in response to an oss-fuzz report that read.c:pseudo_set calls
expr() leaving exp.X_md uninitialised and can copy that to a symbol
via symbol_set_value_expression. tc-i386-intel.c:565 is one place
that later tests the uninitialised X_md.
* config/tc-z80.h (md_expr_init, md_expr_init_rest): Define.
* config/tc-microblaze.h: Likewise.
* expr.c (clean_up_expression): Delete.
(operand): Init expression early.
(expr): Use md_expr_init_rest to init X_md when necessary.
tc-arc.c:tokenize_arguments tweaks expression() parsing, controlling
whether arc_parse_name does anything by setting X_op and X_md in the
expressionS argument passed to expression(). I want to change expr()
to always fully initialise its result, and that means either a special
expression initialiser for arc, or controlling arc_parse_name by some
other means. Since arc_parse_name already tests "assembling_insn" and
no other code does, change "assembling_insn" to directly control
arc_parse_name. Doing it this way also stops a possible uninitialised
access to right.X_op from expr() in arc_parse_name with current gas.
The next patch in this series will also stop such uninitialised
accesses.
* config/tc-arc.c (assembling_insn): Update comment.
(tokenize_arguments): Don't set X_op and X_md to control
expression(), instead just use assembling_insn.
(md_operand): Similarly.
(arc_parse_name): Don't test X_op and X_md.
(md_assemble): Don't set assembling_insn here.
While compilers default to v8plus on 32-bit Solaris/SPARC (gcc at least
since 4.4 in 2009, cc since at least Stdio 9 in 2010), gas still uses a
sparclite default. While this doesn't cause issue for gcc (it passes
-Av8plus as necessary), it repeatedly lead to problems in the testsuite
which has to be sprinkled with setting ASFLAGS accordingly since gas cannot
assemble the gcc output by default.
This patch switches the default to v8plus on Solaris to match gcc.
I had to introduce a new arch value, v8plus-32, matching v9-64, to allow
for this.
I cannot reliably tell if other SPARC targets are similarly affected, so
this patch restricts the change to Solaris.
Tested on sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11.
2025-09-25 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gas:
* config/tc-sparc.c (sparc_arch_table): Introduce v8plus-32.
* configure.tgt (generic_target) <sparc-*-solaris*>: Set arch to
v8plus-32 for 32-bit sparc.
* testsuite/gas/sparc/v8plus.rd, testsuite/gas/sparc/v8plus.s: New
test.
* testsuite/gas/sparc/sparc.exp: Run it on sparc*-*-solaris2*.
Many feature bits were unnecessarily added for features with no command
line flags, and effectively acted as aliases of the architecture version
bit they were linked to. The system register regating patch removed all
uses of these feature bits, so we can just remove them.
Historically we have been inconsistent and overly restrictive in our
choice of features to gate system register accesses. (Originally this
gating was always applied, but now it is disabled unless the
--menable-sysreg-checking option is specified).
This patch updates these constraints, following the principle that we
should only reject a system register access if it requires some
architecture feature or version whose corresponding command line
extension has not been enabled.
The most common change in this patch concerns system registers that
were:
- part of a feature FEAT_X with no corresponding command line extension;
- introduced in a newer architecture version ArmvX.Z;
- permitted to be implemented from an earlier version ArmvX.Y.
Previously these system registers tended to be gated on ArmvX.Z or left
ungated, but following the above principle they are now gated on ArmvX.Y
instead.
Most support for CSRE was removed from Binutils in 2021 after it was
removed from the architecture. This patch removes the remaining system
registers and test files.
Remove all test cases that expect spmzr_el0 to be readable, and remove
some redundant default macro values from armv9_5-a-sysregs.s while we're
there.
Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be
the first test for the "reading from a write-only register" note.
Also remove the recently added -menable-sysreg-checking option from this
test, both to simplify the addition of spmzr_el0 to the test, and to
verify that read/write diagnostics don't depend on that option.
The flag is unnecessary, because we can just unconditionally check the
features field every time. Having the information duplicated in two
separate fields makes it harder to maintain, particularly in the context
of the upcoming regating patch.
The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now
unused, so remove that as well.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
SImilar to aarch64, commit eac4eb8ecb
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 50331d64f1.
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.
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.
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.
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.
"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.
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.
Commit 7ca6020a4e "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.
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').
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.
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.
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>
