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>
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.
