In the past, the .align directive generated a label that did not match
the regular expression, and we set it to XFAIL.
But now it matches fine so it becomes XPASS. We fix it with PASS.
This imports the following commits from GCC as of r15-1722-g7682d115402743:
ca2f7c84927f libiberty: Invoke D demangler when --format=auto
94792057ad4a Fix up duplicated words mostly in comments, part 1
20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957].
52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen
53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size
65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal
This complements and reuses logic from Andreas Krebbel's commit
896a639bab ("s390: Avoid reloc overflows on undefined weak symbols").
Replace relative long addressing instructions of weak symbols, which
will definitely resolve to zero, with either a load address of 0 or a
a trapping insn.
This prevents the PLT32DBL relocation from overflowing in case the
binary will be loaded at 4GB or more.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Replace
instructions using undefined weak symbols with relative
addressing to avoid relocation overflows.
ld/
* testsuite/ld-s390/s390.exp: Add new test.
* testsuite/ld-s390/weakundef-2.s: New test.
* testsuite/ld-s390/weakundef-2.dd: Likewise.
Reported-by: Alexander Gordeev <agordeev@linux.ibm.com>
Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Branch Relative on Count High (brcth) is a conditional branch relative
instruction. It is not guaranteed that it only appears within loops
that sooner or later will take the branch. It may very well be used to
check a condition that will prevent the branch from ever being taken.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Do not replace brcth
referencing undefined weak symbol with a trap.
ld/
* testsuite/ld-s390/weakundef-1.s: Update test case accordingly.
* testsuite/ld-s390/weakundef-1.dd: Likewise.
Fixes: 896a639bab ("s390: Avoid reloc overflows on undefined weak symbols")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
This patch adds support for following sme2.1 zero instructions and
the spec is available here [1].
1. ZERO (single-vector).
2. ZERO (double-vector).
3. ZERO (quad-vector).
The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler
for most of the sme and sve instructions. But for few of the sme2.1
zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory.
To address this a bit "F_VG_REQ" is introduced in this patch, on setting
F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept
instruction operand only having VECTOR GROUP symbols.
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en
This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is
available here [1]
1. LUTI2 (two registers) strided.
2. LUTI2 (four registers) strided.
3. LUTI4 (two registers) strided.
4. LUTI4 (four registers) strided.
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en
':' isn't permitted in macro parameter names, hence this separator
construct isn't necessary at the end of labels. Drop its use in such
cases, for being potentially confusing (and hampering readability, even
if only a little).
As indicated in earlier discussion, permitting GOTTPOFF uniformly for
all legacy non-SIMD insns while at the same time restricting to just
certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns
"equal" to their legacy original ones. Doing that adjustment prevents
another inconsistency, too: In
data16 neg (%rax)
data16 neg (%r16)
data16 {nf} neg (%rax)
it is not logical why the last one shouldn't be permitted. Bypassing
that check requires other adjustments, though, to actually properly
consume (and then squash) the data size prefix.
While there also add the missing CMP and TEST cases to the test case
being modified.
While they properly inherited D and C, code processing the reversal of
operands wasn't updated accordingly (and "reversed" operands also
weren't tested anywhere).
MIPSr6 removes condition trap instructions with imm, so we expand
the instruction like "tne $2,IMM" to
li $at,IMM
tne $2,$at
While if IMM is 0, we can use
tne $2,$zero
only.
the ABI section of the triple explicitly asks for N64,
and in fact GCC also does so.
It can fix the test failure:
FAIL: libdep test: did not get expected output from the linker
with Debian's mipsisa64r6el-linux-gnuabi64 toolchain.
Three extra octets are now expected with the latest change to base64.s.
They happened to be covered by patterns allowing for zero padding at
the end of the section, but we don't want to allow fewer octets than
expected.
PR 31964
* testsuite/gas/all/base64.d: Adjust.
First input_scrub_next_buffer()'s invocation was wrong, leading to input
only being checked from the last newline till the end of the current
buffer. Correcting the invocation, however, leads to duplicate checking
unless -f (or the #NO_APP equivalent thereof) is in effect. Move the
invocation to input_file_give_next_buffer(), to restrict it accordingly.
Then, when macros contain multi-byte characters, warning about them
again in every expansion isn't useful. Suppress such warnings from
sb_scrub_and_add_sb().
Apparently (beyond what's [easily] visible in git history) when this was
added there was confusion about scrubber states vs lex[] contents. For
the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve
to 12) alone is sufficient. "state" is never set to 12, and it being 12
also isn't handled anywhere.
More of a DWARF-generation non-regression test; fixed on the GCC side
with 2024-06-03 "Implement wrap-around arithmetics in DWARF
expressions" (f3d6d60d2ae).
Approved-By: Tom Tromey <tom@tromey.com>
RISC-V Profiles document defines number of "extensions" that indicate
certain platform properties/capabilities just like 'Zkt' extension from the
RISC-V cryptography extensions.
This commit defines 20 platform property/capability extensions as defined
in the RISC-V Profiles documentation.
The only exception: 'Ssstateen' extension is defined separately because it
defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension.
This is based on the ratified version of RISC-V Profiles:
<https://github.com/riscv/riscv-profiles/releases/tag/v1.0>
[Definition]
"Main memory regions":
Main memory regions (in contrast to I/O or vacant memory regions) with
both the cacheability and coherence PMAs.
[New Unprivileged Extensions]
1. 'Ziccif'
"Main memory regions" support instruction fetch and any instruction
fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN)
are atomic.
2. 'Ziccrse'
"Main memory regions" provide the eventual success guarantee for
LR/SC sequence (RsrvEventual).
3. 'Ziccamoa'
"Main memory regions" support all currently-defined AMO operations
including swap, logical and arithmetic operations (AMOArithmetic).
4. 'Za64rs'
For LR/SC instructions, reservation sets are contiguous, naturally
aligned and at most 64-bytes in size.
5. 'Za128rs'
Likewise, but reservation sets are at most 128-bytes in size.
6. 'Zicclsm'
Misaligned loads / stores to "main memory regions" are supported.
Those include both regular scalar and vector accesses but does not
include AMOs and other specialized forms of memory accesses.
7. 'Zic64b'
Cache blocks are (exactly) 64-bytes in size and naturally aligned.
[New Privileged Extensions]
1. 'Svbare'
"satp" mode Bare is supported.
2. 'Svade'
Page-fault exceptions are raised when a page is accessed when A bit is
clear, or written when D bit is clear.
3. 'Ssccptr'
"Main memory regions" support hardware page-table reads.
4. 'Sstvecd'
"stvec" mode Direct is supported. When "stvec" mode is Direct,
"stvec.BASE" is capable of holding any valid 4-byte aligned address.
5. 'Sstvala'
"stval" is always written with a nonzero value whenever possible as
specified in the Privileged Architecture documentation
(version 20211203: see section 4.1.9).
6. 'Sscounterenw'
For any "hpmcounter" that is not read-only zero, the corresponding bit
in "scounteren" is writable.
7. 'Ssu64xl'
"sstatus.UXL" is capable of holding the value 0b10
(UXLEN==64 is supported).
8. 'Shcounterenw'
Similar to 'Sscounterenw' but the same rule applies to "hcounteren".
9. 'Shvstvala'
Similar to 'Sstvala' but the same rule applies to "vstval".
10. 'Shtvala'
"htval" is written with the faulting guest physical address as long as
permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala').
11. 'Shvstvecd'
Similar to 'Sstvecd' but the same rule applies to "vstvec".
12. 'Shvsatpa'
All translation modes supported in "satp" are also supported in "vsatp".
13. 'Shgatpa'
For each supported virtual memory scheme SvNN supported in "satp", the
corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare
is also supported.
[Implications]
(Due to reservation set size constraints)
- 'Za64rs' -> 'Za128rs'
(Due to the fact that a privileged "extension" directly refers a CSR)
- 'Svbare' -> 'Zicsr'
- 'Sstvecd' -> 'Zicsr'
- 'Sstvala' -> 'Zicsr'
- 'Sscounterenw' -> 'Zicsr'
- 'Ssu64xl' -> 'Zicsr'
(Due to the fact that a privileged "extension" indirectly depends on CSRs)
- 'Svade' -> 'Zicsr'
(Due to the fact that a privileged "extension" is a hypervisor property)
- 'Shcounterenw' -> 'H'
- 'Shvstvala' -> 'H'
- 'Shtvala' -> 'H'
- 'Shvstvecd' -> 'H'
- 'Shvsatpa' -> 'H'
- 'Shgatpa' -> 'H'
bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Updated for property
and capability extensions.
(riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm,
ziccrse, za64rs and za128rs extensions.
(riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala,
shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala,
sstvecd, ssu64xlm svade and svbare extensions.
gas/
* testsuite/gas/riscv/imply.d: Updated for property and capability
extensions.
* testsuite/gas/riscv/imply.s: Likewise.
* testsuite/gas/riscv/march-help.l: Likewse.
Fixes a failure on rx-elf where the standard data section isn't .data.
run_dump_test has machinery to translate .data in both options and
expected results for objdump, but not for readelf -x.
PR 31964
* testsuite/gas/all/base64.d: Dump .data with objdump. Run on
all targets.
Skip -z mark-plt tests, which are specific to glibc, on MUSL.
PR ld/31970
* ld/testsuite/ld-x86-64/x86-64.exp: Skip -z mark-plt tests on
MUSL.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was
ignored. This could prevent libsframe.a to be installed in some cases,
the host fetching its canonical value while the target isn't. Both
having a different value, INSTALL_LIBBFD would be false.
There is no need to add a needed glibc version if the glibc base version
includes the needed glibc version.
PR ld/31966
* elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base.
Skip if the glibc base version includes the needed glibc version.
(_bfd_elf_link_add_glibc_version_dependency): Initialize
glibc_minor_base to INT_MAX and pass it to
elf_link_add_glibc_verneed.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
gprofng/ChangeLog
2024-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
* common/hwc_cpus.h: New constant for Intel Ice Lake processor.
* common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel.
Set config1 in perf_event_attr. Remove the use of memset.
* common/core_pcbe.c (core_pcbe_get_eventnum): Return 0.
* common/hwcentry.h: Add config1.
* src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1.
* common/hwcfuncs.c (process_data_descriptor): Set config1.
* common/hwctable.c: Add the hwc table for Intel Ice Lake processor.
* src/hwc_intel_icelake.h: New file.
Add an appendix to provide a rough outline to show how to generate stack
traces using the SFrame format. Such content should hopefully aid the
reader assimmilate the information in the specification.
libsframe/
* doc/sframe-spec.texi: Add new appendix.
This also amends the incorrect comment:
offset3 (intrepreted as FP = CFA + offset2)
If RA tracking is enabled, the offset to recover FP is at the third
index. The SFrame format (V2) has assumption that if FP is saved on
stack, RA must have been saved as well. This is true for the currently
supported arch Aarch64. For AMD64, RA tracking per SFrame FRE is not
necessary.
In future, when extending support for more architectures, this will
likely need to be revisited.
include/
* sframe.h: Make the comments clearer by enumerating what
happens per-ABI.
The recipe to interpret the SFrame FRE stack offsets is
ABI/arch-specific.
Although, there is other information in the specification that is
ABI-specific (like pauth_key usage in AArch64), those pieces of
information are now assimmilated in the SFrame specification in a way
that it is fairly difficult to carve then out into a ABI/arch-specific
section without confusing the readers.
For future though, the specification must strive to keep the generic
parts and ABI/arch-specific parts clearly laid out in separate sections.
libsframe/
* doc/sframe-spec.texi: Reorder and adapt the contents.
Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper
symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO.
Note: Calling unwrap_hash_lookup to check for the wrapper symbol works
only when there is a definition for the wrapped symbol since references
to the wrapped symbol have been redirected to the wrapper symbol.
bfd/
PR ld/31956
* linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol
for wrapper symbol.
include/
PR ld/31956
* bfdlink.h (bfd_link_hash_entry): Add wrapper_symbol.
ld/
PR ld/31956
* plugin.c (get_symbols): Set wrap_status to wrapper if
wrapper_symbol is set.
* testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests.
* testsuite/ld-plugin/pr31956a.c: New file.
* testsuite/ld-plugin/pr31956b.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
This patch adds support for followign SVE2p1 instruction, spec is available here [1].
1. PMOV (to vector)
2. PMOV (to predicate)
Both pmov (to vector) and pmov (to predicate) have destination scalable vector
register and source scalable vector register respectively as an operand with no
suffix and optional index. To handle this case we have added 8 new operands in
this patch.
AARCH64_OPND_SVE_Zn0_INDEX, /* Zn[index], bits [9:5]. */
AARCH64_OPND_SVE_Zn1_17_INDEX, /* Zn[index], bits [9:5,17]. */
AARCH64_OPND_SVE_Zn2_18_INDEX, /* Zn[index], bits [9:5,18:17]. */
AARCH64_OPND_SVE_Zn3_22_INDEX, /* Zn[index], bits [9:5,18:17,22]. */
AARCH64_OPND_SVE_Zd0_INDEX, /* Zn[index], bits [4:0]. */
AARCH64_OPND_SVE_Zd1_17_INDEX, /* Zn[index], bits [4:0,17]. */
AARCH64_OPND_SVE_Zd2_18_INDEX, /* Zn[index], bits [4:0,18:17]. */
AARCH64_OPND_SVE_Zd3_22_INDEX, /* Zn[index], bits [4:0,18:17,22]. */
Since the index of the <Zd> operand is optional, the index part is
dropped in disassembly in both the cases of "no index" or "zero index".
As per spec: PMOV <Zd>{[<imm>]}, <Pn>.D
PMOV <Pn>.D, <Zd>{[<imm>]}
Example1:
Assembly: pmov z5[0], p6.d
Disassembly: pmov z5, p6.d
Assembly: pmov z5, p6.d
Disassembly: pmov z5, p6.d
Example2:
Assembly: pmov p4.b, z5[0]
Disassembly: pmov p4.b, z5
Assembly: pmov p4.b, z5
Disassembly: pmov p4.b, z5
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
