Fix a commit b015e599c7 ("[MIPS] Add new virtualization instructions"),
<https://sourceware.org/ml/binutils/2013-05/msg00118.html>, regression
and bring the disassembly of the RFE instruction back for the relevant
ISA levels.
It is because the "rfe" opcode table entry was incorrectly moved behind
the catch-all generic "c0" entry for CP0 instructions, causing output
like:
00: 42000010 c0 0x10
to be produced rather than:
00: 42000010 rfe
even for ISA levels that do include the RFE instruction.
Move the "rfe" entry ahead of "c0" then, correcting the problem. Add a
suitable test case.
opcodes/
* mips-opc.c (mips_builtin_opcodes): Move the "rfe" entry ahead
of "c0".
gas/
* testsuite/gas/mips/rfe.d: New test.
* testsuite/gas/mips/rfe.s: New test source.
* testsuite/gas/mips/mips.exp: Run the new test.
The two CP1 control registers defined by legacy ISAs used to be referred
to by various names, such as FCR0, FCR31, FSR, however their documented
full names have always been the Implementation and Revision, and Control
and Status respectively, so the FIR and FCSR acronyms coming from modern
ISA revisions will be just as unambiguous while improving the clarity of
disassembly. Do not update the TX39 though as it did not have an FPU.
opcodes/
* mips-dis.c (mips_cp1_names_mips): New variable.
(mips_arch_choices): Use it rather than `mips_cp1_names_numeric'
for "r3000", "r4000", "r4010", "vr4100", "vr4111", "vr4120",
"r4300", "r4400", "r4600", "r4650", "r5000", "vr5400", "vr5500",
"r5900", "r6000", "rm7000", "rm9000", "r8000", "r10000",
"r12000", "r14000", "r16000", "mips5", "loongson2e", and
"loongson2f".
gas/
* testsuite/gas/mips/cp1-names-r3900.d: New test.
* testsuite/gas/mips/mips.exp: Run the new test.
* testsuite/gas/mips/branch-misc-3.d: Update disassembly
according to changes to opcodes.
* testsuite/gas/mips/cp1-names-r3000.d: Likewise.
* testsuite/gas/mips/cp1-names-r4000.d: Likewise.
* testsuite/gas/mips/relax-swap1-mips1.d: Likewise.
* testsuite/gas/mips/relax-swap1-mips2.d: Likewise.
* testsuite/gas/mips/trunc.d: Likewise.
Cover basic CP0, CP2, CP3 move, load and store instructions across the
relevant ISA levels. Omit CP0 move and CP1 instructions as they are
covered elsewhere.
gas/
* testsuite/gas/mips/cp0c.d: New test.
* testsuite/gas/mips/cp0m.d: New test.
* testsuite/gas/mips/r3900@cp0m.d: New test.
* testsuite/gas/mips/cp2.d: New test.
* testsuite/gas/mips/micromips@cp2.d: New test.
* testsuite/gas/mips/cp2m.d: New test.
* testsuite/gas/mips/mipsr6@cp2m.d: New test.
* testsuite/gas/mips/micromips@cp2m.d: New test.
* testsuite/gas/mips/cp2d.d: New test.
* testsuite/gas/mips/mipsr6@cp2d.d: New test.
* testsuite/gas/mips/micromips@cp2d.d: New test.
* testsuite/gas/mips/cp2-64.d: New test.
* testsuite/gas/mips/micromips@cp2-64.d: New test.
* testsuite/gas/mips/cp3.d: New test.
* testsuite/gas/mips/cp3m.d: New test.
* testsuite/gas/mips/cp3d.d: New test.
* testsuite/gas/mips/cp0c.s: New test source.
* testsuite/gas/mips/cp0m.s: New test source.
* testsuite/gas/mips/cp2.s: New test source.
* testsuite/gas/mips/cp2m.s: New test source.
* testsuite/gas/mips/cp2d.s: New test source.
* testsuite/gas/mips/cp2-64.s: New test source.
* testsuite/gas/mips/cp3.s: New test source.
* testsuite/gas/mips/cp3m.s: New test source.
* testsuite/gas/mips/cp3d.s: New test source.
* testsuite/gas/mips/mips.exp: Run the new tests.
The CP0 control register set has never been defined, however encodings
for the CFC0 and CTC0 instructions remained available for implementers
up until the MIPS32 ISA declared them invalid and causing the Reserved
Instruction exception[1]. Therefore we handle them for both assembly
and disassembly, however in the latter case the names of CP0 registers
from the regular set are incorrectly printed if named registers are
requested. This is because we do not define separate operand classes
for coprocessor regular and control registers respectively, which means
the disassembler has no way to tell the two cases apart. Consequently
nonsensical disassembly is produced like:
cfc0 v0,c0_random
Later the MIPSr5 ISA reused the encodings for XPA ASE MFHC0 and MTHC0
instructions[2] although it failed to document them in the relevant
opcode table until MIPSr6 only.
Correct the issue then by defining a new register class, OP_REG_CONTROL,
and corresponding operand codes, `g' and `y' for the two positions in
the machine instruction a control register operand can take. Adjust the
test cases affected accordingly.
While at it swap the regular MIPS opcode table "cfc0" and "ctc0" entries
with each other so that they come in the alphabetical order.
References:
[1] "MIPS32 Architecture For Programmers, Volume II: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 1.00, August 29, 2002, Table A-9 "MIPS32 COP0 Encoding of
rs Field", p. 242
[2] "MIPS Architecture For Programmers, Volume II-A: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 5.04, December 11, 2013, Section 3.2 "Alphabetical List of
Instructions", pp. 195, 216
include/
* opcode/mips.h: Document `g' and `y' operand codes.
(mips_reg_operand_type): Add OP_REG_CONTROL enumeration
constant.
gas/
* tc-mips.c (convert_reg_type) <OP_REG_CONTROL>: New case.
(macro) <M_TRUNCWS, M_TRUNCWD>: Use the `g' rather than `G'
operand code.
opcodes/
* mips-dis.c (print_reg) <OP_REG_COPRO>: Move control register
handling code over to...
<OP_REG_CONTROL>: ... this new case.
* mips-opc.c (decode_mips_operand) <'g', 'y'>: New cases.
(mips_builtin_opcodes): Update "cfc1", "ctc1", "cttc1", "cttc2",
"cfc0", "ctc0", "cfc2", "ctc2", "cfc3", and "ctc3" entries
replacing the `G' operand code with `g'. Update "cftc1" and
"cftc2" entries replacing the `E' operand code with `y'.
* micromips-opc.c (decode_micromips_operand) <'g'>: New case.
(micromips_opcodes): Update "cfc1", "cfc2", "ctc1", and "ctc2"
entries replacing the `G' operand code with `g'.
binutils/
* testsuite/binutils-all/mips/mips-xpa-virt-1.d: Correct CFC0
operand disassembly.
* testsuite/binutils-all/mips/mips-xpa-virt-3.d: Likewise.
The TX39 core has its distinct set of CP0 registers[1], so it needs a
separate table to hold their names. Add a test case accordingly.
References:
[1] "32-Bit RISC Microprocessor TX39 Family Core Architecture User's
Manual", Toshiba, Jul. 27, 1995, Section 2.2.2 "System control
coprocessor (CP0) registers", pp. 9-10
opcodes/
* mips-dis.c (mips_cp0_names_r3900): New variable.
(mips_arch_choices): Use it rather than `mips_cp0_names_numeric'
for "r3900".
gas/
* testsuite/gas/mips/cp0-names-r3900.d: New test.
* testsuite/gas/mips/mips.exp: Run it.
The DMTC1 instruction operates on a floating-point general register as
its second operand, however in the disassembly of the microMIPS encoding
a floating-point control register is shown instead. This is due to an
incorrect ordering of the two "dmtc1" entries in the opcode table, which
gives precedence to one using the `G' aka coprocessor format over one
using the `S' or floating-point register format.
The coprocessor format, or OP_REG_COPRO, is used so that GAS supports
referring to FPRs by their numbers in assembly, such as $0, $1, etc.
however in the case of CP1/FPU it is also used by the disassembler to
decode those numbers to the names of corresponding control registers.
This in turn causes nonsensical disassembly such as:
dmtc1 a1,c1_fir
in a reference to $f0. It has been like this ever since microMIPS ISA
support has been added.
Correct the ordering of the two entries then by swapping them with each
other, making disassembly output consistent with the regular MIPS DMTC1
instruction as well all the remaining CP1 move instructions. Adjust all
the test cases affected accordingly.
opcodes/
* micromips-opc.c (micromips_opcodes): Swap the two "dmtc1"
entries with each other.
gas/
* testsuite/gas/mips/micromips.d: Update disassembly according
to "dmtc1" entry fix with opcodes.
* testsuite/gas/mips/micromips-compact.d: Likewise.
* testsuite/gas/mips/micromips-insn32.d: Likewise.
* testsuite/gas/mips/micromips-noinsn32.d: Likewise.
* testsuite/gas/mips/micromips-trap.d: Likewise.
* testsuite/gas/mips/micromips@isa-override-1.d: Likewise.
Fix an issue caused by commit f9419b056f ("MIPS gas: code cleanup"),
<https://sourceware.org/ml/binutils/2002-05/msg00192.html>, and replace
the incorrect use of RA with the CFC1 and CTC1 instructions with FCSR.
While the register referred by its number is $31 in both cases, these
instructions operate on the floating-point control register file rather
than general-purpose registers.
gas/
* config/tc-mips.c (FCSR): New macro.
(macro) <M_TRUNCWS, M_TRUNCWD>: Use it in place of RA.
commit a7664973b2
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Apr 26 10:41:35 2021 +0200
x86: correct overflow checking for 16-bit PC-relative relocs
caused linker failure when building 16-bit program in a 32-bit ELF
container. Update GNU_PROPERTY_X86_FEATURE_2_USED with
#define GNU_PROPERTY_X86_FEATURE_2_CODE16 (1U << 12)
to indicate that 16-bit mode instructions are used in the input object:
https://groups.google.com/g/x86-64-abi/c/UvvXWeHIGMA
to indicate that 16-bit mode instructions are used in the object to
allow linker to properly perform relocation overflow check for 16-bit
PC-relative relocations in 16-bit mode instructions.
1. Update x86 assembler to always generate the GNU property note with
GNU_PROPERTY_X86_FEATURE_2_CODE16 for .code16 in ELF object.
2. Update i386 and x86-64 linkers to use 16-bit PC16 relocations if
input object is marked with GNU_PROPERTY_X86_FEATURE_2_CODE16.
bfd/
PR ld/27905
* elf32-i386.c: Include "libiberty.h".
(elf_howto_table): Add 16-bit R_386_PC16 entry.
(elf_i386_rtype_to_howto): Add a BFD argument. Use 16-bit
R_386_PC16 if input has 16-bit mode instructions.
(elf_i386_info_to_howto_rel): Update elf_i386_rtype_to_howto
call.
(elf_i386_tls_transition): Likewise.
(elf_i386_relocate_section): Likewise.
* elf64-x86-64.c (x86_64_elf_howto_table): Add 16-bit
R_X86_64_PC16 entry.
(elf_x86_64_rtype_to_howto): Use 16-bit R_X86_64_PC16 if input
has 16-bit mode instructions.
* elfxx-x86.c (_bfd_x86_elf_parse_gnu_properties): Set
elf_x86_has_code16 if relocatable input is marked with
GNU_PROPERTY_X86_FEATURE_2_CODE16.
* elfxx-x86.h (elf_x86_obj_tdata): Add has_code16.
(elf_x86_has_code16): New.
binutils/
PR ld/27905
* readelf.c (decode_x86_feature_2): Support
GNU_PROPERTY_X86_FEATURE_2_CODE16.
gas/
PR ld/27905
* config/tc-i386.c (set_code_flag): Update x86_feature_2_used
with GNU_PROPERTY_X86_FEATURE_2_CODE16 for .code16 in ELF
object.
(set_16bit_gcc_code_flag): Likewise.
(x86_cleanup): Always generate the GNU property note if
x86_feature_2_used isn't 0.
* testsuite/gas/i386/code16-2.d: New file.
* testsuite/gas/i386/code16-2.s: Likewise.
* testsuite/gas/i386/x86-64-code16-2.d: Likewise.
* testsuite/gas/i386/i386.exp: Run code16-2 and x86-64-code16-2.
include/
PR ld/27905
* elf/common.h (GNU_PROPERTY_X86_FEATURE_2_CODE16): New.
ld/
PR ld/27905
* testsuite/ld-i386/code16.d: New file.
* testsuite/ld-i386/code16.t: Likewise.
* testsuite/ld-x86-64/code16.d: Likewise.
* testsuite/ld-x86-64/code16.t: Likewise.
* testsuite/ld-i386/i386.exp: Run code16.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
Since the policies of GNU and llvm toolchain are different for now,
current binutils mainline cannot accept any draft extensions, including
rvv, zfh, .... The Clang/LLVM allows these draft stuff on mainline,
but the GNU ld might be used with them, so this causes the link time
problems.
The patch allows ld to link the objects with unknown prefixed extensions,
which are probably generated by LLVM or customized toolchains.
bfd/
* elfxx-riscv.h (check_unknown_prefixed_ext): New bool.
* elfxx-riscv.c (riscv_parse_prefixed_ext): Do not check the
prefixed extension name if check_unknown_prefixed_ext is false.
* elfnn-riscv.c (riscv_merge_arch_attr_info): Set
check_unknown_prefixed_ext to false for linker.
gas/
* config/tc-riscv.c (riscv_set_arch): Set
check_unknown_prefixed_ext to true for assembler.
When assembling a forward reference the symbol will be unknown and so during
do_t_adr we cannot set the thumb bit. The bit it set so early to prevent
relaxations that are invalid. i.e. relaxing a Thumb2 to Thumb1 insn when the
symbol is Thumb.
But because it's done so early we miss the case for forward references.
This patch changes it so that we additionally check the thumb bit during the
internal relocation processing.
In principle we should be able to only set the bit during reloc processing but
that would require changes to the other relocations that the instruction could
be relaxed to.
This approach still allows early relaxations (which means that we have less
iteration of internal reloc processing) while still fixing the forward reference
case.
gas/ChangeLog:
2021-05-24 Tamar Christina <tamar.christina@arm.com>
PR gas/25235
* config/tc-arm.c (md_convert_frag): Set LSB when Thumb symbol.
(relax_adr): Thumb symbols 4 bytes.
* testsuite/gas/arm/pr25235.d: New test.
* testsuite/gas/arm/pr25235.s: New test.
This patch clarify the following invalid combinations of march and mabi,
* ilp32f/lp64f abi without f extension.
* ilp32d/lp64d abi without d extension.
* ilp32q/lp64q abi without q extension.
* e extension with any abi except ilp32e
GNU assembler reports errors when finding the above invalid combinations.
But LLVM-MC reports warnings and ignores these invalid cases. It help to
set the correct ilp32/lp64/ilp32e abi according to rv32/rv64/rve. This
looks good and convenient, so perhaps we can do the same things. However,
if you don't set the mabi, GNU assembler also try to set the suitable
ABI according to march/elf-attribute. Compared to LLVM-MC, we will choose
double/quad abi if d/f extension is set.
gas/
PR 25212
* config/tc-riscv.c (riscv_set_abi_by_arch): If -mabi isn't set, we
will choose ilp32e abi for rv32e. Besides, report errors for the
invalid march and mabi combinations.
* testsuite/gas/riscv/mabi-attr-rv32e.s: New testcase. Only accept
ilp32e abi for rve extension.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.d: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.d: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise.
Renamed all mabi testcases to their march-mabi settings.
* config/tc-z80.c (emit_data_val): Warn on constant overflow.
(signed_overflow): New function.
(unsigned_overflow): New function.
(is_overflow): Use new functions.
(md_apply_fix): Use signed_overflow.
* testsuite/gas/z80/ez80_adl_suf.d: Fix test.
* testsuite/gas/z80/ez80_isuf.s: Likewise.
* testsuite/gas/z80/ez80_z80_suf.d: Likewise.
gas/ChangeLog:
2021-05-19 John Buddery <jvb@cyberscience.com>
PR 25599
* config/tc-ia64.c (emit_one_bundle): Increment fixup offset
by one for PCREL60B relocation on HP-UX.
The initial problem I wanted to fix here is that GAS was rejecting MVE
instructions such as:
vmov q3[2], q3[0], r2, r2
with:
Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2'
which is incorrect; such instructions are valid. Note that for moves in
the other direction, e.g.:
vmov r2, r2, q3[2], q3[0]
GAS is correct in rejecting this as it does not make sense to move both
lanes into the same register (the Arm ARM says this is CONSTRAINED
UNPREDICTABLE).
After fixing this issue, I added assembly/disassembly tests for these
vmovs. This revealed several disassembly issues, including incorrectly
marking the moves into vector lanes as UNPREDICTABLE, and disassembling
many of the vmovs as vector loads. These are now fixed.
gas/ChangeLog:
* config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving
into the same GPR twice.
* testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message.
* testsuite/gas/arm/mve-vmov-3.d: New test.
* testsuite/gas/arm/mve-vmov-3.s: New test.
opcodes/ChangeLog:
* arm-dis.c (mve_opcodes): Fix disassembly of
MVE_VMOV2_GP_TO_VEC_LANE when idx == 1.
(is_mve_encoding_conflict): MVE vector loads should not match
when P = W = 0.
(is_mve_unpredictable): It's not unpredictable to use the same
source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).
PR 27823
* config/tc-z80.c (emit_ld_r_m): Report an illegal load
instruction.
* testsuite/gas/z80/ill_ops.s: New test source file.
* testsuite/gas/z80/ill_ops.d: New test driver.
* testsuite/gas/z80/ill_ops.l: New test error output.
Use the pattern from other projects where we generate the html pages
in a dir named the same as the project. So now we have:
gas/doc/gas.html - single html page
gas/doc/gas/ - multiple html pages
This works for projects that have a doc/ subdir already, but gprof &
ld require a little tweaking since they generate their docs in their
respective toplevels.
This better matches other GNU projects like autoconf/automake where
the html manual is the single page form. We'll support the multi-page
form in a follow up change.
x86-64 uses rela relocations. The comment next to the field's declaration
says "Non-zero values for ELF USE_RELA targets should be viewed with
suspicion ..." And indeed the fields being non-zero causes section
contents to be accumulated into the final relocated values in addition to
the relocations' addends, which is contrary to the ELF spec.
Surely disp processing should access the disp operand, not an imm one.
This is not an active issue only because imms and disps are, at the
moment, overlapping fields of the same union.
i386_finalize_immediate() is used for both AT&T and Intel immediate
operand handling. Move an AT&T-only check to i386_immediate(), which at
the same time allows it to cover other cases as well, giving an overall
better / more consistent diagnostic.
- Drop a pointless & where just before it was checked that the
respective bits are clear already anyway.
- Avoid a not really necessary operand_type_set() and a redundant
operand_type_or() / operand_type_and() pair.
The gotha() relocation mnemonic will be outputted by OpenRISC GCC when
using the -mcmodel=large option. This relocation is used along with
got() to generate 32-bit GOT offsets. This increases the previous GOT
offset limit from the previous 16-bit (64K) limit.
This is needed on large binaries where the GOT grows larger than 64k.
bfd/ChangeLog:
PR 21464
* bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation.
* elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise.
(or1k_final_link_relocate, or1k_elf_relocate_section,
or1k_elf_check_relocs): Likewise.
* libbfd.h (bfd_reloc_code_real_names): Likewise.
* reloc.c: Likewise.
cpu/ChangeLog:
PR 21464
* or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic
for gotha() relocation.
include/ChangeLog:
PR 21464
* elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number.
opcodes/ChangeLog:
PR 21464
* or1k-asm.c: Regenerate.
gas/ChangeLog:
PR 21464
* testsuite/gas/or1k/reloc-1.s: Add test for new relocation.
* testsuite/gas/or1k/reloc-1.d: Add test result for new
relocation.
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
fixup reloc, add tests
Now that lex_got() is uniform for all targets using it, permit COFF
targets to also use @secrel32 with, in particular, .long. This is more
natural than the custom .secrel32 directive, and also allows more
flexibility (the "+six" form of the two added test lines doesn't work
with a .secrel32 equivalent, in that it silently produces an unintended
relocation type).
As an extra benefit this also makes sure that data definitions in Intel
syntax mode would get treated like they do for e.g. ELF targets.
I see no reason at all for us to carry two copies of almost identical
code. The differences, apart from the table entries, are benign. And
the #ifdef-ary doesn't really get any worse.
Allow a few more expression forms when the entire expression can be
resolved at assembly time. For this, i386_validate_fix() needs to
arrange for all processing of the relocation to be deferred to
tc_gen_reloc().
So far this (counter-intuitively) produced the size as recorded in the
(section) symbol. Obtain the section's size instead for section symbols.
(I wonder whether STT_SECTION symbols couldn't properly hold the
section's size in their st_size field, which in turn would likely mean
the internal symbol would also have its size properly updated.)
Note that this is not the same as the .sizeof.() pseudo-operator: @size
yields the local file's contribution to a section, while .sizeof.() gets
resolved by the linker to produce the final full section's size.
As to the 3rd each of the expected output lines in the changed testcase:
I can't find justification for zzz to come after yyy despite them being
defined in the opposite order in source. Therefore I think it's better
to permit both possible outcomes.
PR gas/27763
While the comment in output_jump() was basically correct prior to the
introduction of 64-bit mode, both that and the not-JMP-like behavior of
XBEGIN require adjustments: Branches with 32-bit displacement do not
wrap at 4G in 64-bit mode, and XBEGIN with 16-bit operand size doesn't
wrap at 64k. Similarly %rip-relative addressing doesn't wrap at 4G.
The new testcase points out that for PE/COFF object_64bit didn't get
set so far, preventing in particular the check at the end of
md_convert_frag() to take effect.
For Mach-O the new testcase fails (bogusly), in that only the first two
of the expected errors get raised. Since for Mach-O many testcases
already fail, and since an x86_64-darwin target can't even be configured
for, I didn't think I need to bother.
Note that there are further issues in this area, in particular for
branches with operand size overrides. Such branches, which truncate
%rip / %eip, can't be correctly expressed with ordinary PC-relative
relocations. It's not really clear what to do with them - perhaps the
best we can do is to carry through all associated relocations, leaving
it to the linker (or even loader) to decide (once the final address
layout is known). Same perhaps goes for relocations associated with
32-bit addressing in 64-bit mode.
Add () to !i.prefix[ADDR_PREFIX] to silence GCC 5:
gas/config/tc-i386.c:4152:31: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
&& !i.prefix[ADDR_PREFIX] != (flag_code == CODE_32BIT))
^
* config/tc-i386.c (optimize_encoding): Add () to silence GCC 5.
Over the years I've seen a number of instances where people used
lea (%reg1), %reg2
or
lea symbol, %reg
despite the same thing being expressable via MOV. Since additionally
LEA often has restrictions towards the ports it can be issued to, while
MOV typically gets dealt with simply by register renaming, transform to
MOV when possible (without growing opcode size and without altering
involved relocation types).
Note that for Mach-O the new 64-bit testcases would fail (for
BFD_RELOC_X86_64_32S not having a representation), and hence get skipped
there.
Constants not known at the time an individual insn gets assembled and
going into a sign-extended field still shouldn't be silently truncated
at the time the respective fixup gets resolved.
The change implementing the .persistent family of sections broke the
existing support for the .persistent.bss section in the compiler:
int a __attribute__ ((section (".persistent.bss")));
t.s: Assembler messages:
t.s:4: Warning: setting incorrect section type for .persistent.bss
The compiler encodes it as @nobits but the assembler expects @progbits.
The assembler is incorrect and should treat the section like the compiler.
bfd/
* elf.c (special_sections_p): Add .persistent.bss.
gas/
* testsuite/gas/elf/section25.d: Run it everywhere.
* testsuite/gas/elf/section26.d: Likewise.
* testsuite/gas/elf/section26.s: Add test for .persistent.bss.
LEA behavior without a 64-bit destination is independent of address size
- in particular LEA with 32-bit addressing and 64-bit destination is the
same as LEA with 64-bit addressing and 32-bit destination. IOW checking
merely i.prefix[ADDR_PREFIX] is insufficient. This also means wrong
relocation types (R_X86_64_32S when R_X86_64_32 is needed) were used so
far in such cases.
Note that in one case in build_modrm_byte() the 64-bit check came too
early altogether, and hence gets dropped in favor of the one included in
the new helper. This is benign to non-64-bit code from all I can tell,
but the failure to clear disp16 could have been a latent problem.
