Trying to build binutils with an older gcc currently fails. Working
around these gcc bugs is not onerous so let's fix them.
bfd/
* elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun
pointer.
* elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat"
variable to "status".
gas/
* compress-debug.c (compress_finish): Supply all fields in
ZSTD_inBuffer initialisation.
include/
* xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
forward declaration.
opcodes/
* loongarch-opc.c: Supply all fields of zero struct initialisation
in various opcode tables.
Testing for NULL in pic_need_relax fixes the other call to this
function in md_estimate_size_before_relax.
PR 28955
* config/tc-mips.c (mips_frob_file): Move NULL sym test to..
(pic_need_relax): ..here.
There are two problems: symbol_equated_p() doesn't recognize equates of
registers, and S_CAN_BE_REDEFINED() goes by section rather than by
expression type. Both together undermine .eqv and .equiv clearly meaning
to guard the involved symbols against re-definition (both ways).
To compensate pseudo_set() now using O_symbol and S_CAN_BE_REDEFINED()
now checking for O_register,
- for targets creating register symbols through symbol_{new,create}() ->
symbol_init() -> S_SET_VALUE() (alpha, arc, dlx, ia64, m68k, mips,
mmix, tic4x, tic54x, plus anything using cgen or itbl-ops), have
symbol_init() set their expressions to O_register,
- x86'es parse_register() also can't go by section anymore when
trying to "look through" equates; probably symbol_equated_p() should
have been used there from the beginning, if only that had worked for
equates of registers,
- various targets need to "look through" equates when parsing insn
operands (which also helps transitive forward equates); perhaps even
more ought to, but many don't look to consider the possibility of
register equates in the first place.
This was uncovered by code reported in PR gas/30274 (duplicating
PR gas/30272), except that there .eqv was used when really .equ was
meant. Therefore that bug report is addressed here only in so far as
gas wouldn't crash anymore; the code there still won't assemble
successfully, just that now the issues there are properly diagnosed.
As per the spec merely a blank isn't okay as a separator, the operand
to the relocation function ought to be parenthesized. Enforcing this
then also eliminates an inconsistency in that
lui t0, %hi sym
lui t0, %hi 0x1000
were accepted, but
lui t0, %hi +sym
lui t0, %hi -0x1000
were not.
char is unsigned on s390x, so there are a lot of warnings like:
gas/config/tc-bpf.c: In function 'get_token':
gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits]
900 | if (ch == EOF || len > MAX_TOKEN_SZ)
| ^~
Change its type to int, like in the other similar code.
There is also:
gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized]
735 | dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]);
| ~~~~~~~~~~~^~~~~~~~~~
-Wmaybe-uninitialized doesn't seem to understand the FSM; just
initialize bpf_endianness to silence it. Add an assertion to
build_bpf_endianness() in order to catch potential bugs.
bfd/doc/chew.c extracts documentation from source code comments
annotated with keywords, and generates much of bfd.h and libbfd.h from
those same comments. The docs have suffered from people (me too)
adding things like CODE_FRAGMENT to the source to put code into bfd.h
without realising that CODE_FRAGMENT also puts @example around said
code into the docs. So we have random senseless things in the docs.
This patch fixes that problem (well, the senseless things from
CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
few chew.c features. libbfd.h now automatically gets ATTRIBUTE_HIDDEN
prototypes, and indentation in bfd.h and libbfd.h is better.
... out of mainline code, grouping together the two case labels. This
then also make more obvious that the comment there applies to both forms
of shifts.
Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
and prefix last, resulting in fewer table entries. Note that in the
course of the re-work wrong M_0 suffixes are also corrected to be M_1
(partly infixes now).
Since it ended up confusing while testing the change, also adjust the
test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).
Ventana Micro has published the specification for their
XVentanaCondOps ("conditional ops") extension at
https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
which contains two new instructions
- vt.maskc
- vt.maskcn
that can be used in constructing branchless sequences for
various conditional-arithmetic, conditional-logical, and
conditional-select operations.
To support such vendor-defined instructions in the mainline binutils,
this change also adds a riscv_supported_vendor_x_ext secondary
dispatch table (but also keeps the behaviour of allowing any unknow
X-extension to be specified in addition to the known ones from this
table).
As discussed, this change already includes the planned/agreed future
requirements for X-extensions (which are likely to be captured in the
riscv-toolchain-conventions repository):
- a public specification document is available (see above) and is
referenced from the gas-documentation
- the naming follows chapter 27 of the RISC-V ISA specification
- instructions are prefixed by a vendor-prefix (vt for Ventana)
to ensure that they neither conflict with future standard
extensions nor clash with other vendors
bfd/ChangeLog:
* elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
(riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
gas/ChangeLog:
* doc/c-riscv.texi: Add section to list custom extensions and
their documentation URLs.
* testsuite/gas/riscv/x-ventana-condops.d: New test.
* testsuite/gas/riscv/x-ventana-condops.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
opcodes/ChangeLog:
* riscv-opc.c: Add vt.maskc and vt.maskcn.
Series-version: 1
Series-to: binutils@sourceware.org
Series-cc: Kito Cheng <kito.cheng@sifive.com>
Series-cc: Nelson Chu <nelson.chu@sifive.com>
Series-cc: Greg Favor <gfavor@ventanamicro.com>
Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
This patch expands the GAS manual in order to specify the alternate
pseudo-C assembly syntax used in BPF, and now supported by the
assembler.
gas/ChangeLog:
2023-04-19 Jose E. Marchesi <jose.marchesi@oracle.com>
PR gas/29757
* doc/c-bpf.texi (BPF Pseudo-C Syntax): New section.
This patch expands the GAS BPF testsuite in order to also test the
alternative pseudo-C syntax used in BPF assembly.
This includes three main changes:
- Some general GAS tests involving assignment and equality operands in
expressions (such as = and ==) are disabled in bpf-* targets,
because the syntax collides with the pseudo-C BPF assembly syntax.
- New tests are added to the BPF GAS testsuite that test the pseudo-c
syntax. Tests for all BPF instructions are included.
- New tests are added to the BPF GAS testsuite that test the support
for both syntaxes in the same source.
gas/ChangeLog:
2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
PR gas/29728
* testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
targets.
* testsuite/gas/all/eqv-dot.d: Likewise.
* testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.
* testsuite/gas/bpf/alu-pseudoc.s: New file.
* testsuite/gas/bpf/pseudoc-normal.s: Likewise.
* testsuite/gas/bpf/pseudoc-normal.d: Likewise.
* testsuite/gas/bpf/pseudoc-normal-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/lddw-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump32-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump-pseudoc.s: Likewise.
* testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise.
* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests.
This patch adds support to the GNU assembler for an alternative
assembly syntax used in BPF. This syntax is C-like and very
unconventional for an assembly language, but it is generated by
clang/llvm and is also used in inline asm templates in kernel code, so
we ought to support it.
After this patch, the assembler is able to parse instructions in both
supported syntax: the normal assembly-like syntax and the pseudo-C
syntax. Instruction formats can be mixed in the source program: the
assembler recognizes the right syntax to use.
gas/ChangeLog:
2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
PR gas/29728
* config/tc-bpf.h (TC_EQUAL_IN_INSN): Define.
* config/tc-bpf.c (LEX_IS_SYMBOL_COMPONENT): Define.
(LEX_IS_WHITESPACE): Likewise.
(LEX_IS_NEWLINE): Likewise.
(LEX_IS_ARITHM_OP): Likewise.
(LEX_IS_STAR): Likewise.
(LEX_IS_CLSE_BR): Likewise.
(LEX_IS_OPEN_BR): Likewise.
(LEX_IS_EQUAL): Likewise.
(LEX_IS_EXCLA): Likewise.
(ST_EOI): Likewise.
(MAX_TOKEN_SZ): Likewise.
(init_pseudoc_lex): New function.
(md_begin): Call init_pseudoc_lex.
(valid_expr): New function.
(build_bpf_non_generic_load): Likewise.
(build_bpf_atomic_insn): Likewise.
(build_bpf_jmp_insn): Likewise.
(build_bpf_arithm_insn): Likewise.
(build_bpf_endianness): Likewise.
(build_bpf_load_store_insn): Likewise.
(look_for_reserved_word): Likewise.
(is_register): Likewise.
(is_cast): Likewise.
(get_token): Likewise.
(bpf_pseudoc_to_normal_syntax): Likewise.
(md_assemble): Try pseudo-C syntax if an instruction cannot be
parsed.
write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used
* write.c (chain_frchains_together_1): Rewrite loop as a do
while to avoid false positive -Wdangling-pointer.
Special casing GPR names in my_getSmallExpression() leads to a number of
inconsistencies. Generalize this by utilizing the md_parse_name() hook,
limited to when instruction operands are being parsed (really: probed).
Then both the GPR lookup there and the yet more ad hoc workaround for
PR/gas 29940 can be removed (including its extension needed for making
the compressed form JAL work again).
Both the temporary workaround for PR/gas 29940 and the existing special
casing of GPRs in my_getSmallExpression() aren't really tested anywhere
(i.e. with the workarounds remove testing would still succeed). Nor is
there any test for uses of symbols with names matching GPRs, where such
is permitted. Before altering how this is to be dealt with, install two
testcases covering the expected behavior. (For now this includes only
known affected insns; re-ordering of entries in riscv_opcodes[] could,
however, yield more of them.)
With my_getSmallExpression() consistently and silently failing on
relocation operators not fitting an insn, it is no longer necessary to
hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a
subsequent parsing attempt for another operand combination might
succeed). This also eliminates the latent problem of percent_op_itype[]
and percent_op_stype[] growing a non-identical set of recognized
relocation operators.
The use of a wrong (for the insn) relocation operator (or a future one
which simply isn't recognized by older gas yet) doesn't render the (rest
of the) expression "bad". Furthermore alongside the error from
expression() in most cases the parser would emit another error then
anyway. Suppress the call to my_getExpression() in such a case,
arranging for a guaranteed subsequent error message by marking the
expression "illegal".
Both callers check for no relocations, so there's no point parsing for
some. Have the function pass percent_op_null into
my_getSmallExpression(). Note that there's no point passing
percent_op_itype: Elsewhere, especially when processing compressed alias
insns ahead of non-alias ones, this has the effect of avoiding "bad
expression" errors when another parsing pass may follow (and succeed).
Here, however, all alternative forms of an insn type will again start
with the same O4 or O2, so avoiding errors earlier on doesn't really
help. Plus constructs with a relocation specifier (as percent_op_itype
would permit) can't be specified anyway, as the scrubber eats the
whitespace between .insn's type and the O4 or O2 expression when that
starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
riscv_ip() looks only for whitespace when finding the end of a mnemonic.
The sole caller of parse_relocation() has already checked for the %
prefix, so there's no need to check for it again in the strncasecmp()
and there's also no reason to make the involved string literals longer
than necessary.
-mfix-looongson3-llsc may add sync instructions not needed on some
asm code with lots of debug info.
PR: 30153
* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.
If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.
The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o
For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.
For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.
In commit 6967633c8b ("x86: convert testcases to use .insn") an ILP32
clone of a testcase was missed in the set of tests needing --divide
added.
Reported-by: Clément Chigot <chigot@adacore.com>
gas/
* gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
consistently.
(output_sframe): Likewise.
(sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.
Callers which want to make further parsing attempts at the buffer passed
to the function need to be aware that due to the potential of string
concatenation the input buffer may be altered in ways beyond what can be
undone by putting back at *input_line_pointer the character that the
function returns.
This reverts the code change done by 100f993c53 ("x86: Check
unbalanced braces in memory reference"), which wrongly identified
e87fb6a6d0 ("x86/gas: support quoted address scale factor in AT&T
syntax") as the root cause of PR gas/30248. (The testcase is left in
place, no matter that it's at best marginally useful in that shape.)
The problem instead is that parse_register() alters the string handed to
it, thus breaking valid assumptions in subsequent parsing code. Since
the function's behavior is a result of get_symbol_name()'s, make a copy
of the incoming string before invoking that function.
Like for parse_real_register() follow the model of strtol() et al: input
string is const-qualified to signal that the string isn't altered, but
the returned "end" pointer is not const-qualified, requiring const to be
cast away (which generally is a bad idea, but the alternative would
again be more convoluted code).
Follow the model of strtol() et al - input string is const-qualified to
signal that the string isn't altered, but the returned "end" pointer is
not const-qualified, requiring const to be cast away (which generally is
a bad idea, but the alternative would be more convoluted code).
The double store/loads instructions (e.g. STD/LDD) are not baseline
ARC ISA. The same holds for some short instructions. Update the
tests to use base ARC ISA.
Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
While I was working on the disassembler styling for ARM I noticed that
the whitespace in the cpsie instruction was inconsistent with most of
the other ARM disassembly output, the disassembly for cpsie looks like
this:
cpsie if,#10
notice there's no space before the '#10' immediate, most other ARM
instructions have a space before each operand.
This commit updates the disassembler to add the missing space, and
updates the tests I found that tested this instruction.
tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places
cannot be represented in type 'int'.
* config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left
shift.
This commit intends to move operands that require very special handling or
operand types that are so minor (e.g. only useful on a few instructions)
under "W". I also intend this "W" to be "temporary" operand storage until
we can find good two character (or less) operand type.
In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved
to "Wif" because of its special handling (and allocating single character
"f" for this operand type seemed too much).
Current expected allocation guideline is as follows:
1. 'W'
2. The most closely related single-letter extension in lowercase
(strongly recommended but not mandatory)
3. Identify operand type
The author currently plans to allocate following three-character operand
types (for operands including instructions from unratified extensions).
1. "Wif" ('Zicbop': fetch offset)
2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions)
3. "Wfm" / "WfM"
'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling
solely for widening conversion instructions.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from
"f" to "Wif".
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Move from "f" to "Wif".
* riscv-opc.c (riscv_opcodes): Reflect new operand type.
This can't be done for all insns currently encoded with .byte. For one
outside of 64-bit mode unused (typically ignored) register encoding bits
in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
the necessary registers cannot be specified (and some of these bits
can't even be used outside of 64-bit mode). And then there are odd tests
like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
together with EVEX.W (which could be expressed; note though EVEX.W set
is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
because that's another #UD reason).
In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
byte but insufficient displacement bytes, some using SIB encoding with
the SIB byte actually being the supposed immediate. Some of these could
be expressed by .insn, but I don't want to introduce bogus examples.
These will all need adjustment anyway once the disassembler is improved
in the way it deals with unrecognized encodings.
Generally generated code is meant to remain the same. {,x86-64-}nops.d
are exceptions because insn prefixes are emitted in a different order.
opcode{,-intel,-suffix}.d are also adjusted (along with an according
correction to opcode.s) to cover an apparent typo in the original tests
(xor when or was meant).
Where necessary --divide is added as gas option, to allow for the use
of the extension opcode functionality.
Comments are being adjusted where obviously wrong/misleading.
Since we have no insn suffix and it's also not realistic to infer
immediate size from the size of other (typically register) operands
(like optimize_imm() does), and since we also don't have a template
telling us permitted size(s), a new syntax construct is introduced to
allow size (and signedness) specification. In the absence of such, the
size is inferred from significant bits (which obviously may yield
inconsistent results at least for effectively negative values, depending
on whether BFD64 is enabled), and only if supplied expressions can be
evaluated at parsing time. Being explicit is generally recommended to
users.
Size specification is permitted at bit granularity, but of course the
eventually emitted immediate values will be padded up to 8-, 16-, 32-,
or 64-bit fields.
Alan Modra
Jan Beulich
YunQiang Su
Ilya Leoshkevich
Jose E. Marchesi
Philipp Tomsich
Guillermo E. Martinez
mengqinggang
Indu Bhagat
Thomas Koenig
Claudiu Zissulescu
Claudiu Zissulescu
Haochen Jiang
Andrew Burgess
Tsukasa OI