Commit 012d442686 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>
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.
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.
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.
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.
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
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.
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.
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'.
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.
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.
The original patch,
e6f372ba66
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.
The custom parsing done there and in one of its callers allowed various
bogus constructs to be accepted. Insist on a non-zero leading digit when
parsing numbers, don't lose upper bits, and insist on proper separation
of operands.
Commit 1ac26e9f7a replaced ISSPACE with is_whitespace, but the
former returns true on EOL while the latter does not. Sprinkle
is_end_of_stmt tests to fix this bug.
The same segfault can be triggered by a ".relax_hint" with no
following instructions. Fix that too.
* config/tc-nds32.c (nds32_lookup_pseudo_opcode): Use
is_end_of_stmt along with is_whitespace.
(nds32_relax_relocs, nds32_relax_hint, nds32_flag),
(ict_model: Likewise.
(nds32_elf_append_relax_relocs): Return on no opcode.
* testsuite/gas/nds32/nds32.exp: Find .d files automatically.
* testsuite/gas/nds32/pr33229.d,
* testsuite/gas/nds32/pr33229.s: New test.
Add faminmax, move a couple of misplaced entries, and improve a few
other entries.
The documentation now lists every recognised extension name, with the
exception of a couple of aliases that are deliberately undocumented.
over gas directive to emit .sframe section.
Fix PR gas/33175 sframe: --gsframe=no does not disable when
.cfi_sections directive with .sframe
--gsframe=no should also disable generation of SFrame section when
explicit CFI directive:
.cfi_sections .sframe
is specified in the input. This means we need to track whether SFrame
generation was explicitly disabled by the user. Introduce a new enum to
facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and
GEN_SFRAME_DISABLED.
While fixing the bug by adding the enum, keep the upcoming requirement
in mind: we will also need to disambiguate between
--enable-default-sframe and user-specified --gsframe/--gsframe=yes. The
intent is to not display SFrame related warnings or errors like:
as_bad (_(".sframe not supported for target"));
for unsupported targets if --enable-default-sframe is in effect.
This implies we need to have a four state enum (
GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED,
GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED)
gas/
PR gas/33175
* dw2gencfi.c (cfi_finish): Check state of flag_gen_sframe to
determine whether any SFrame section is generated.
* as.h (enum gen_sframe_option): New definition.
* as.c (parse_args): Keep track of whether the flag is
explicitly enabled or disabled
gas/testsuite/
PR gas/33175
* gas/cfi-sframe/cfi-sframe-common-1.d: Remove redundant
--gsframe.
* gas/cfi-sframe/cfi-sframe.exp: Add new test.
* gas/cfi-sframe/cfi-sframe-common-1c.d: New test. No SFrame
section if explicit --gsframe=no.
* gas/cfi-sframe/cfi-sframe-common-1c.s: New test.
SFrame generation code assumes that since DW_CFA_restore means
restoration of the state of the register to the one at the beginning of
the function, there must be a state to restore to (hence the gas_assert
(cie_fre)).
This assumption needs adjustment. DW_CFA_restore may be present in the
very beginning of a (e.g., cold) function, with no initialized state for
SFrame functions to restore to.
gas/
PR gas/33170
* gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if
CIE FRE is not yet setup.
gas/testsuite/
PR gas/33170
* gas/cfi-sframe/cfi-sframe.exp: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.
.bundle_align_mode 32
nop
read.c:776:26: runtime error: shift exponent 32 is too large for
32-bit type 'unsigned int'
Avoid this by using wider types in the expressions.
I omitted documentation in 8aad677a12 in
error. Rectify that with:
1) changing ---help to mention bare `--gsframe` too, as we're not
getting rid of that;
2) adding the new --gsframe=[no|yes] form to as.texi.
PR gas/33125
* gas/as.c (parse_args): Tweak --gsframe= help text.
* gas/doc/as.texi: Document --gsframe=[no|yes].
Being able to explicitly disable SFrames on the command line is useful,
especially when looking at a gas that enables SFrames by default. The
binutils testsuite will benefit from this as there's testcases that don't
expect their presence.
In summary:
* Nothing is passed => no SFrames (no change from before)
* --gsframe is passed => SFrames (no change from before)
* --gsframe=yes is passed => SFrames (previously rejected)
* --gsframe-no is passed => no SFrames (previously rejected)
PR gas/33125
* gas/as.c (parse_args): Accept --gsframe=no, --gsframe=yes.
Being able to explicitly disable SFrames on the command line is useful,
especially when looking at a gas that enables SFrames by default. The
binutils testsuite will benefit from this as there's testcases that don't
expect their presence.
In summary:
* Nothing is passed => no SFrames (no change from before)
* --gsframe is passed => SFrames (no change from before)
* --gsframe=yes is passed => SFrames (previously rejected)
* --gsframe-no is passed => no SFrames (previously rejected)
PR gas/33125
* gas/as.c (parse_args): Accept --gsframe=no, --gsframe=yes.
asan complains when running the gas all/cond-diag test.
* read.c (deferred_diag_head, deferred_diag_tail): Renamed
from deferred_diags and last_deferred_diag, making the tail
pointer a deferred_diag**.
(s_errwarn_if): Simplify appending to list. Free unused diag
on error.
(evaluate_deferred_diags): Free list.
Move gas_sframe_check to binutils-common.exp so that it can be used in
linker tests to check if a target assembler supports --gsframe.
binutils/
PR ld/33146
* testsuite/lib/binutils-common.exp (gas_sframe_check): Moved
from cfi-sframe.exp. Replace gas_host_run with remote_exec.
gas/
PR ld/33146
* testsuite/gas/cfi-sframe/cfi-sframe.exp (gas_sframe_check):
Moved to binutils-common.exp.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Process a new aarch64-specific CFI directive: .cfi_mte_tagged_frame
(LLVM uses this CFI directive already). The CFI directive, when
present for a function, indicates that the stack frame for the
function may modify the MTE tags of the stack space it uses. The
assembler emits char 'G' in the CIE augmentation string to indicate
the same.
ChangeLog:
* gas/config/tc-aarch64.c (s_aarch64_mte_tagged_frame): New
definition.
* gas/config/tc-aarch64.h (tc_fde_entry_extras): Add
memtag_frame_p.
(tc_cie_entry_extras): Likewise.
(tc_fde_entry_init_extra): Likewise.
(tc_cie_fde_equivalent_extra): Likewise.
(tc_cie_entry_init_extra): Likewise.
* gas/doc/c-aarch64.texi: Add documentation for
.cfi_mte_tagged_frame directive.
* gas/testsuite/gas/aarch64/mte_tagged_stack.d: New test.
* gas/testsuite/gas/aarch64/mte_tagged_stack.s: New test.
Add a new flag -menable-sysreg-checking to restore previous behaviour.
This existing behaviour is quite inconsistent, so the gating will
probably be updated in the future. (In particular, many system
registers are currently gated with the architecture version they were
released with instead of the lower architecture version that they
actually require).
This patch retains the +d128 requirement for msrr/mrrs.
Co-Authored-By: Srinath Parvathaneni <srinath.parvathaneni@arm.com>
By default, NIL qualifiers are treated as matching any qualifier when
checking operand constraints. For many SVE instructions, this would
allow operands with missing type suffixes to be assembled as if they had
any explicit type specified. To prevent this, the F_STRICT flag is used
to specify that NIL qualifiers should match only NIL qualifiers.
Unfortunately, several SVE instructions incorrectly omitted this
F_STRICT flag. The bug has existed in the *MATMUL_SVE* macros since
they were added in 2019. The macro LUT_SVE2_INSN was added last year,
and the other incorrect macros are new in this release.
LUTv2_SME2_INSN and LUTv2_SME2p1_INSN were not actually broken, because
we reject untyped vector lists already during parsing. However, I have
added the F_STRICT flag here anyway, since this is more consistent and
would be more robust if those operands start accepting untyped vector
lists in the future. The new luti4 tests are the only ones that were
already rejected before this change.
BFLOAT16_SVE_INSN has been unused since it was originally added, so I
just deleted the macro.
The SVE LUT instructions were using the lut instruction class, which
has special handling only for SIMD operands, and isn't recognised by
aarch64_decode_variant_using_iclass (which sets the qualifiers during
decode for most SVE instructions). To prevent these instructions
failing to disassemble, I changed their instruction class to sve_misc.
