The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries
to be memory sealed by the loader, to avoid further changes of
PT_LOAD segments (such as unmapping or change permission flags).
This is done along with Linux kernel (the mseal syscall [1]), and
C runtime supports to instruct the kernel on the correct time during
program startup (for instance, after RELRO handling). This support
is added along the glibc support to handle the new gnu property [2].
This is a opt-in security features, like other security hardening
ones like NX-stack or RELRO.
The new property is ignored if present on ET_REL objects, and only
added on ET_EXEC/ET_DYN if the linker option is used. A gnu property
is used instead of DT_FLAGS_1 flag to allow memory sealing to work
with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports
still do no support static-pie).
H.J. Lu [Tue, 14 Jan 2025 01:09:28 +0000 (09:09 +0800)]
ld: Update mixed LTO and non-LTO relocatable output tests
Since mixed LTO and non-LTO relocatable output is only supported on ELF
platforms, limit these tests to ELF targets. Since powerpc64 elfv1
defines a function symbol on its procedure descriptor, which is in a
data section, rather than on the code for that function, allow both D
and T for nm test on mixed object.
* testsuite/ld-plugin/lto.exp: Limits mixed LTO and non-LTO
relocatable output tests to ELF targets. Allow both D and T for
nm test on mixed object.
Matthieu Longo [Thu, 21 Nov 2024 18:44:22 +0000 (18:44 +0000)]
aarch64 SFrame: skip with warning new CFI directive used with pauth_lr
Today, SFrame v2 specification does not describe how to encode the
information corresponding to the PAuth_LR PAC signing method (it only
supports PAuth PAC signing method).
SFrame v3 specification should hopefully specify it.
In the meantime, if the GNU assembler finds .cfi_negate_ra_state_with_pc
and --gsframe is specified, it will output a warning to the user and
will fail to generate the FDE entry.
A new SFrame test for .cfi_negate_ra_state_with_pc is also added to
reflect this issue.
Matthieu Longo [Mon, 25 Nov 2024 12:17:56 +0000 (12:17 +0000)]
aarch64 DWARF: add new CFI directive for PAuth_LR
This patch adds a new CFI directive (cfi_negate_ra_state_with_pc) which
set an additional bit in the RA state to inform that RA was signed with
SP but also PC as an additional diversifier.
RA state | Description
0b00 | Return address not signed (default if no cfi_negate_ra_state*)
0b01 | Return address signed with SP (cfi_negate_ra_state)
0b10 | Invalid state
0b11 | Return address signed with SP+PC (cfi_negate_ra_state_with_pc)
Approved-by: Indu Bhagat <indu.bhagat@oracle.com> Approved-by: Jan Beulich <jbeulich@suse.com>
Matthieu Longo [Thu, 21 Nov 2024 18:40:41 +0000 (18:40 +0000)]
aarch64 SFrame: use preferred CFI directive for AArch64 PAC
ARMv8.3 addded support for a new security feature named Pointer
Authentication. Support for this feature in SFrame already exists.
In GCC 14 and older, the Sparc DWARF extension .cfi_gnu_window_save
is emitted instead of .cfi_negate_ra_state.
GCC 15 fixed this issue, but this behavior is preserved for backward
compatibility.
The existing sframe test for AArch64 PAC was using .cfi_gnu_window_save.
This patch replaces this CFI in the existing test by the preferred one,
and adds a new test to check for backward compatibility when using
.cfi_gnu_window_save.
Matthieu Longo [Thu, 21 Nov 2024 18:44:07 +0000 (18:44 +0000)]
aarch64: make explicit that CFI gnu_window_save is for Sparc, not AArch64
- add a detailed comment when parsing DW_CFA_GNU_window_save in SFrame to
explain why we are checking whether the targeted architecture is AArch64,
whereas this CFI is a Sparc extension.
- replace .cfi_gnu_window_save by .cfi_negate_ra_state in existing AArch64
DWARF tests as this is the preferred directive since GCC 15.
- add a new AArch64 test to check backward compatibility with old GCC
versions that emits .cfi_gnu_window_save.
Approved-by: Indu Bhagat <indu.bhagat@oracle.com> Approved-by: Richard Earnshaw <richard.earnshaw@arm.com>
gdbserver: remove handling of the 'L' tracepoint action
Now that static tracepoint support is removed from gdbserver, it makes
sense to remove handling of the 'L' tracepoint action, too. The code
that checks received actions already has a default case that tolerates
unrecognized actions:
gdbserver: remove the static_tracepoint enum value
As a continuation of the previous patches that remove UST from
gdbserver, remove the `static_tracepoint` enum value from
`tracepoint_type` and all the associated code.
Now that the last use of `write_e_static_tracepoints_not_supported`
is gone, also remove that function.
The handling of the 'S' option, where the `static_tracepoint` enum
value was being used, is removed completely, because recognizing that
option makes sense only when static tracepoint support is announced.
This patch is easier to view with "git show -w".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: do not announce static tracepoint support
Remove the announcement that `qXfer:statictrace:read` and
`StaticTracepoints` are supported. Associated to this, remove the
handling of "qTfSTM", "qTsSTM", and "qTSTMat" packets and the
qXfer:statictrace:read handling.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: remove UST (static tracepoint) support (part 2)
With the removal of UST, the `in_process_agent_supports_ust` query
would essentially always be false. Remove the function and adjust
the uses, comments, and warning/error messages.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbserver: remove UST (static tracepoint) support (part 1)
UST support in gdbserver is substantially outdated. Simon says:
...[having HAVE_UST defined] never happens nowadays because it used
a version of lttng-ust that has been deprecated for a loooong time
(the 0.x series). So everything in HAVE_UST just bitrots. It might
be possible to update all this code to use lttng-ust 2.x (1.x never
existed), but I don't think it's going to happen unless somebody
specifically asks for it. I would suggest removing support for UST
from gdbserver. ...If we ever want to resurrect the support for UST
and port to 2.x, we can get the code from the git history.
This patch removes the support, mostly mechanically by deleting code
guarded by `#ifdef HAVE_UST`. After these removals, `struct
static_tracepoint_ctx` becomes unused. So, remove it, too.
The following patches remove more code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb, doc: mention the 'S' option for the QTDP packet
I noticed that gdbserver accepts an 'S' option for the QTDP packet to
create a static tracepoint, but this is not mentioned in the document.
Update the document.
I first thought about updating the argument as `[:Flen|:S]`, but then
opted for `[:Flen][:S]`. Although it is odd that ':F' and ':S' are
allowed to co-exist, the implementation at the gdbserver side allows
this and handles the packet arguments so that the right-most
positioned ':F' or ':S' overwrites the final tracepoint type. When
the documentation is missing, the implementation usually determines
the behavior.
Haochen Jiang [Tue, 14 Jan 2025 02:30:44 +0000 (10:30 +0800)]
x86: Remove "NE" in mnemonics for convert insns related to AI data types
NE is quite ambiguous and misleading in mnemonics since it should be
Rounding to Nearest Even, but could be mis-interpretated to No
Exception.
Under its correct meaning, which means rounding, it should only be used
in down-convert, since up-convert is always exact for normal values
It could be difficult to judge which kind of convert it is if we have
the convert between same bit float types.
For all AI data types including BF16 and FP8, the default rounding is
Rounding to Nearest Even. So removing them in mnemonics would reduce
burden for programmers to consider whether it should be added or not
in mnemonics and stop the ambiguous meaning on "NE" itself.
If the convert itself is using a rounding mode other than RNE, it would
be explicitly added in mnemonics (e.g., Long used "T" and "BIAS"
introduced in AVX10.2).
Haochen Jiang [Tue, 14 Jan 2025 02:30:43 +0000 (10:30 +0800)]
x86: Rename VCOMSBF16 to VCOMISBF16
The functionality for VCOMSBF16 is exactly the same as the VCOMISD/S/H.
The only difference is the bf16 type. Thus, it should be VCOMISBF16.
This patch would fix that.
Haochen Jiang [Tue, 14 Jan 2025 02:30:42 +0000 (10:30 +0800)]
x86: Remove "P" and "NE" in mnemonics for BF16 arithmetic insns
Since the bf16 is an AI data types, it will be implicitly packed. Thus,
"P" (for packed) is omitted in mnemonics from its introduction. AVX10.2
BF16 arithmetic insns are introduced with "P" in mnemonics with packed.
This patch will remove them for consistency.
NE is quite ambiguous and misleading in mnemonics since it should be
Rounding to Nearest Even, but could be mis-interpretated to No
Exception. While AI data types like BF16 and FP8 are using Rounding to
Nearest Even as default rounding modes. There is no need to use the
ambiguous mnemonics in AVX10.2 insns. This patch will also remove them.
For convert insns, it will be handled in the upcoming patch.
Hu, Lin1 [Tue, 14 Jan 2025 02:30:38 +0000 (10:30 +0800)]
Support Intel AMX-MOVRS
This patch will support AMX-MOVRS feature. Unlike all the other
AMX insns in vector space where we pass vex_len_table before
vex_w_table, we first pass vex_w_table for tileloaddrs[,t1] to
align with the order in EVEX space. The reason why we first pass
vex_w_table in EVEX space is due to AMX-AVX512, where tcvtrowd2ps
and tilemovrow with r32 shares the same opcode with tileloaddrs[,t1].
All of them have evex.w = 0 but with different evex.length. Re-doing
that shortly is not ideal.
APX_F extension is also implemented in this patch. The encoding will
be:
- EVEX.128.NP/66.MAP5.W0 F8/F9 !(11):rrr:100 for
T2RPNTLVW[Z0,Z1]RS[,T1] with NF=0.
- EVEX.128.F2/66.0F38.W0 4A !(11):rrr:100 FOR TILELOADDRS[,T1] with
NF=0.
For APX_F extension, we could not use APX_F(AMX_TRANSPOSE&AMX_MOVRS)
since the transformation could not be done. Instead, we will use
AMX_TRANSPOSE & APX_F(AMX_MOVRS). Thus, we should set AMX_TRANSPOSE
for "any" for cpu_flags in assembler. Since it will only affect the
cpu_flags_match, handle that there.
gas/ChangeLog:
* config/tc-i386.c (cpu_arch): Add amx_movrs.
(cpu_flags_match): Set any bitfield for multiple cpuid
enabled insns.
* doc/c-i386.texi: Document .amx_movrs.
* testsuite/gas/i386/x86-64.exp: Run AMX-MOVRS tests.
* testsuite/gas/i386/x86-64-amx-movrs-intel.d: New test.
* testsuite/gas/i386/x86-64-amx-movrs-inval.l: Ditto.
* testsuite/gas/i386/x86-64-amx-movrs-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-movrs.d: Ditto.
* testsuite/gas/i386/x86-64-amx-movrs.s: Ditto.
Hu, Lin1 [Tue, 14 Jan 2025 02:30:36 +0000 (10:30 +0800)]
Support Intel MOVRS
This patch focus on supporting MOVRS ISA. We could take this full ISA
as four part: PREFETCHRST2, MOVRS, MOVRS APX_F extension and MOVRS AVX10.2
extension.
The APX_F extension for MOVRS will be:
- EVEX.LLZ.NP.MAP4.WIG 8A !(11):rrr:bbb for r8/m8 with NF=0 and
ND=0
- EVEX.LLZ.NP/66.MAP4.SCALABLE 8B !(11):rrr:bbb for rv/mv with NF=0
and ND=0
We did not merge the table together for APX_F since there is an explicit
x64 for movrs insn. The current APX_F() did not support the combination
between CPUIDs. Also, the space is different for legacy and apx_f forms.
Haochen Jiang [Tue, 14 Jan 2025 02:30:32 +0000 (10:30 +0800)]
x86: Remove mod_table pass for MVexSIBMEM
When using MVexSIBMEM, OP_M will help check modrm. Thus, no need
to pass mod_table.
Since we have OP_M do the work, from now on, mod_table[] should
not gain any new entries, unless both slots of them are populated,
e.g., different modrm leading to different insns could not be
combined (Bad_Opcode is not the case since OP_M could handle that).
opcodes/ChangeLog:
* i386-dis.c: Remove mod_table pass for MVexSIBMEM.
H.J. Lu [Mon, 4 Nov 2013 17:17:45 +0000 (09:17 -0800)]
ld: Add LTO and none-LTO output support for ld -r
Link with mixed IR/non-IR objects
* 2 kinds of object files
o non-IR object file has
* non-IR sections
o IR object file has
* IR sections
* non-IR sections
* The output of "ld -r" with mixed IR/non-IR objects should work with:
o Compilers/linkers with IR support.
o Compilers/linkers without IR support.
* Add the mixed object file which has
o IR sections
o non-IR sections:
* Object codes from IR sections.
* Object codes from non-IR object files.
o Object-only section:
* With section name ".gnu_object_only" and SHT_GNU_OBJECT_ONLY type
on ELF:
https://gitlab.com/x86-psABIs/Linux-ABI
#define SHT_GNU_OBJECT_ONLY 0x6ffffff8 /* Object only */
* Contain non-IR object file.
* Input is discarded after link.
* Linker action:
o Classify each input object file:
* If there is a ".gnu_object_only" section, it is a mixed object file.
* If there is a IR section, it is an IR object file.
* Otherwise, it is a non-IR object file.
o Relocatable non-IR link:
* Prepare for an object-only output.
* Prepare for a regular output.
* For each mixed object file:
* Add IR and non-IR sections to the regular output.
* For object-only section:
* Extract object only file.
* Add it to the object-only output.
* Discard object-only section.
* For each IR object file:
* Add IR and non-IR sections to the regular output.
* For each non-IR object file:
* Add non-IR sections to the regular output.
* Add non-IR sections to the object-only output.
* Final output:
* If there are IR objects, non-IR objects and the object-only
output isn't empty:
* Put the object-only output into the object-only section.
* Add the object-only section to the regular output.
* Remove the object-only output.
o Normal link and relocatable IR link:
* Prepare for output.
* IR link:
* For each mixed object file:
* Compile and add IR sections to the output.
* Discard non-IR sections.
* Object-only section:
* Extract object only file.
* Add it to the output.
* Discard object-only section.
* For each IR object file:
* Compile and add IR sections to the output.
* Discard non-IR sections.
* For each non-IR object file:
* Add non-IR sections to the output.
* Non-IR link:
* For each mixed object file:
* Add non-IR sections to the output.
* Discard IR sections and object-only section.
* For each IR object file:
* Add non-IR sections to the output.
* Discard IR sections.
* For each non-IR object file:
* Add non-IR sections to the output.
This is useful for Linux kernel build with LTO.
bfd/
PR ld/12291
PR ld/12430
PR ld/13298
* bfd.c (bfd_lto_object_type): Add lto_mixed_object.
(bfd): Add object_only_section.
(bfd_group_signature): New.
* elf.c (special_sections_g): Add .gnu_object_only.
* format.c: Include "plugin-api.h" and "plugin.h" if
BFD_SUPPORTS_PLUGINS is defined.
(bfd_set_lto_type): Set type to lto_mixed_object for
GNU_OBJECT_ONLY_SECTION_NAME section.
(bfd_check_format_matches): Don't check the plugin target twice
if the plugin target is explicitly specified.
* opncls.c (bfd_extract_object_only_section): New.
* plugin.c (bfd_plugin_fake_text_section): New.
(bfd_plugin_fake_data_section): Likewise.
(bfd_plugin_fake_bss_section): Likewise.
(bfd_plugin_fake_common_section): Likewise.
(bfd_plugin_get_symbols_in_object_only): Likewise.
* plugin.c (add_symbols): Call
bfd_plugin_get_symbols_in_object_only and count
plugin_data->object_only_nsyms.
(bfd_plugin_get_symtab_upper_bound): Count
plugin_data->object_only_nsyms.
bfd_plugin_get_symbols_in_object_only and add symbols from
object only section.
(bfd_plugin_canonicalize_symtab): Remove fake_section,
fake_data_section, fake_bss_section and fake_common_section.
Set udata.p to NULL. Use bfd_plugin_fake_text_section,
bfd_plugin_fake_data_section, bfd_plugin_fake_bss_section and
bfd_plugin_fake_common_section.
Set udata.p to NULL.
* plugin.h (plugin_data_struct): Add object_only_nsyms and
object_only_syms.
* section.c (GNU_OBJECT_ONLY_SECTION_NAME): New.
* bfd-in2.h: Regenerated.
In AIX a recent commit caused a build break with the error as shown below.
In file included from python/py-color.h:23,
from python/python.c:39:
python/python-internal.h:86:10: fatal error: Python.h: No such file or directory
86 | #include <Python.h>
In AIX, we run builds with and without python for our internal CI's.
A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690
missed to guard Python.h in HAVE_PYTHON macro.
Tom Tromey [Mon, 6 Jan 2025 14:45:33 +0000 (07:45 -0700)]
Handle case where DAP line can be None
A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting. In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.
Jan Beulich [Mon, 13 Jan 2025 12:32:19 +0000 (13:32 +0100)]
bfd/ELF: slightly "better" file alignment for object files
PR gas/32435
Commit 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object
files") caused an issue in the Linux kernels modpost utility, which was
building upon .rodata sections to be 4-byte aligned in the file when
they have 4-byte alignment. While we don't want to revert back to
original behavior, apply the same alignment "capping" as done originally
in two other places also for "ordinary" sections.
Simon Marchi [Mon, 13 Jan 2025 03:29:51 +0000 (22:29 -0500)]
gdb/jit: use correctly-sized array view in deprecated_frame_register_read call
Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in
register reading and unwinding") introduces a regression in
gdb.base/jit-reader.exp:
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
Program received signal SIGTRAP, Trace/breakpoint trap.
Recursive internal problem.
The "Recusive internal problem" part is not good, but it's not the point
of this patch. It still means we hit an internal error.
The stack trace is:
#0 internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53
#1 0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...)
at /home/simark/src/binutils-gdb/gdb/frame.c:1207
#2 0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496
#3 0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988
#4 0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100
#5 0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143
#6 0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 <jit_frame_unwind>, this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042
#7 0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 <jit_frame_unwind>) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138
#8 0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209
#9 0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996
#10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033
The problem is that function `jit_unwind_reg_get_impl` passes field
`gdb_reg_value::value`, a gdb_byte array of 1 element (used as a
flexible array member), as the array view parameter of
`deprecated_frame_register_read`. This results in an array view of size
1. The assertion in `frame_register_unwind` that verifies the passed in
buffer is larger enough to hold the unwound register value then fails.
Fix this by explicitly creating an array view of the right size.
Andrei Pikas [Sat, 5 Oct 2024 19:27:44 +0000 (22:27 +0300)]
Add an option with a color type.
Colors can be specified as "none" for terminal's default color, as a name of
one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.,
as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an
integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard
colors. Integers 8-15 are used for the so-called bright colors from the
aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm
extended 256-color palette (usually 6x6x6 cube plus gray ramp). In
general, 256-color palette is terminal dependent and sometimes can be
changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\".
It is the responsibility of the user to verify that the terminal supports
the specified colors.
PATCH v5 changes: documentation fixed.
PATCH v6 changes: documentation fixed.
PATCH v7 changes: rebase onto master and fixes after review.
PATCH v8 changes: fixes after review.
Tom Tromey [Wed, 8 Jan 2025 01:10:19 +0000 (18:10 -0700)]
Use std::vector in linespec_state
This changes linespec_state to use a std::vector, and changes
linespec_canonical_name to use std::string. This removes some manual
memory management, including some odd cleanup code in in
decode_line_full.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 8 Jan 2025 01:03:28 +0000 (18:03 -0700)]
Use gdb::unordered_set in linespec_state
This patch changes linespec_state to use gdb::unordered_set. This
simplifies the code a little and removes some manual management. It
also replaces address_entry with a std::pair, which simplifies the
code even more; and since this is a private type, IMO it doesn't
reduce readability at all.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
GDB: Use gdb::array_view for buffers used in register reading and unwinding
This allows checking the size of the given buffer. Changes
frame_register_unwind (), frame_unwind_register (), get_frame_register ()
and deprecated_frame_register_read ().
As pointed out by Baris, in the case of MIPS target code this is best
done by changing a couple of alloca-based buffers in
mips_read_fp_register_single and mips_print_fp_register to
gdb::byte_vector instances.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
aarch64: Add support for FEAT_SVE_B16B16 min and max instructions.
This patch adds support for SME Z-targeting multi-vector non-widening
BFloat16 instructions, under tick FEAT_SVE_B16B16 and command line flag
"+sve-b16b16+sme2".
Also the test files related to FEAT_SVE_B16B16 (+sme2) are prefixed with
sve-b16b16-sme2*.
eg: sve-b16b16-sme2-1.s, sve-b16b16-sme2-1.d.
The spec for this feature and instructions is availabe here [1]:
[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en
In the current code, SVE2 Bfloat16 instructions are implemented with tick
FEAT_B16B16 and command line flag "+b16b16" and this feature was suspended
due to incomplete support.
In the new spec available here[1], FEAT_B16B16 is replaced with
FEAT_SVE_B16B16 and command line flag "+b16b16" is replace with "sve-b16b16".
Also the test files related to FEAT_SVE_B16B16 are prefixed with sve-b16b16*.
eg: sve-b16b16-sve2-1.s, sve-b16b16-sve2-1.d.
This patch supports the SVE Z-targeting non-widening BFloat16 instructions
with command line flag "+sve-b16b16+sve2".
[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SVE-Instructions?lang=en
Tom Tromey [Tue, 7 Jan 2025 20:54:17 +0000 (13:54 -0700)]
Minor test case updates for gnat-llvm
gnat-llvm seems to be a bit more aggressive about eliminating unused
variables. This patch improves the test results a tiny bit by
arranging for some variables to appear to be used.
Note the copyright dates on the new files are done that way because I
simply copied existing files.
aarch64: Add support for FEAT_SME_F16F16 fcvt and fcvtl instructions.
This patch adds support for FEAT_SME_F16F16 instructions fcvt and fcvtl,
which are available on passing command line flags +sme-f16f16 and the
spec is available here[1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en
aarch64: Add support for FEAT_SME_F16F16 fmla and fmls instructions.
This patch adds support for FEAT_SME_F16F16 instructions fmla and fmls,
which are available on passing command line flags +sme-f16f16 and the
spec is available here[1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en
aarch64: Add support for FEAT_SME_F16F16 fmops and fmopa instructions.
This patch adds support for FEAT_SME_F16F16 instructions fmops and fmopa,
which are available on passing command line flags +sme-f16f16 and the
spec is available here[1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en
This patch adds support for FEAT_SME_F16F16 feature (Non-widening
half-precision FP16 to FP16 arithmetic for SME2), which is enabled
using command line flags +sme-f16f16 to -march (which enables both
FEAT_SME2 and FEAT_SME_F16F16).
There are couple of instructions (fadd and fsub variants) which should
be allowed by the assembler on either passing +sme-f16f16 or +sme-f8f16.
Those instructions are already supported in the current assembler, this
patch adds tests for those instructions as well.
Tom de Vries [Fri, 10 Jan 2025 09:32:00 +0000 (10:32 +0100)]
[gdb/tdep] Fix gdb.cp/non-trivial-retval.exp on riscv64-linux
With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into:
...
(gdb) finish^M
Run till exit from #0 f1 (i1=i1@entry=23, i2=i2@entry=100) \
at non-trivial-retval.cc:34^M
main () at non-trivial-retval.cc:163^M
163 B b = f2 (i1, i2);^M
Value returned is $6 = {a = -5856}^M
(gdb) FAIL: $exp: finish from f1
...
where "Value returned is $6 = {a = 123}" is expected.
The problem is that gdb thinks that the return value is in $a0:
...
$ gdb -q -batch non-trivial-retval \
-ex "b f1" \
-ex run \
-ex "set debug riscv infcall on" \
-ex finish
Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1".
Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34
34 {
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
[riscv-infcall] riscv_return_value: \
[R] type: 'A', length: 0x4, alignment: 0x4, register a0
main () at non-trivial-retval.cc:163
163 B b = f2 (i1, i2);
Value returned is $1 = {a = -3568}
...
while $a0 actually contains a pointer to the returned value 123:
...
(gdb) p /x $a0
$3 = 0x3ffffff210
(gdb) p *((unsigned int *)$a0)
$5 = 123
...
The returned type is:
...
class A
{
public:
A () {}
A (A &obj);
int a;
};
...
which is a C++ aggregate with a nontrivial (because it's user-defined) copy
constructor:
According to the ABI [1], indeed this is returned by reference:
...
Values are returned in the same manner as a first named argument of the same
type would be passed. If such an argument would have been passed by
reference, the caller allocates memory for the return value, and passes the
address as an implicit first parameter.
...
Aggregates larger than 2×XLEN bits are passed by reference and are replaced in
the argument list with the address, as are C++ aggregates with nontrivial copy
constructors, destructors, or vtables.
...
Fix this in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_copy_constructible.
The vtable case is explictly mentioned in the ABI, but AFAIU already covered
by the nontrivial copy constructor case.
The nontrivial destructor case is also not supported, but the testsuite
doesn't seem to trigger this.
Fix this by:
- extending the test-case to cover this scenario, and
- fixing it in riscv_call_arg_scalar_int by checking for
language_pass_by_reference ().trivially_destructible.
Tom de Vries [Fri, 10 Jan 2025 07:53:29 +0000 (08:53 +0100)]
[gdb/testsuite] Fix gdb.rust/completion.exp timeout on riscv64-linux
On riscv64-linux, with test-case gdb.rust/completion.exp I run into the
following timeout:
...
(gdb) complete break pars^M
FAIL: gdb.rust/completion.exp: complete break pars (timeout)
...
Replaying the scenario outside the testsuite show us that the command takes
~13 seconds:
...
$ gdb -q -batch -x gdb.in
...
2025-01-08 12:23:46.853 - command started
+complete break pars
break parse.rs
break parse_printf_format
break parse_running_mmaps_unix.rs
break parser.rs
2025-01-08 12:23:59.600 - command finished
Command execution time: 12.677752 (cpu), 12.748565 (wall)
...
while the timeout is 10 seconds.
The riscv64 processor on the server (cfarm91) is not fast (a fair amount of
the skip_huge_test test-cases times out), but something else is going on as
well.
For x86_64-linux, roughly measuring the size of debug info in the exec get us:
...
$ readelf -wi outputs/gdb.rust/completion/completion | wc -l
2007
...
while on the riscv64 server I get:
...
$ readelf -wi outputs/gdb.rust/completion/completion | wc -l 1606950
...
So it seems reasonable that the test is somewhat slower on riscv64.
Jan Beulich [Fri, 10 Jan 2025 07:43:02 +0000 (08:43 +0100)]
gas: consolidate . latching
... by purging dot_{frag,value}. Right now these two and dot_symbol are
updated independently, which can't be quite right. Centralize .-related
information in dot_symbol, updating it also where previously
dot_{frag,value} were updated. Since S_GET_VALUE() can't be used to
retrieve what used to be dot_value, introduce a new helper to fetch both
frag and offset.
Jan Beulich [Fri, 10 Jan 2025 07:42:41 +0000 (08:42 +0100)]
aarch64: re-work PR gas/27217 fix again
Commit c1723a8118f0 ("Arm64: re-work PR gas/27217 fix") really was only
a band-aid; Nick's original solution to the problem was technically
preferable, yet didn't work when . came into play. Undo most of that
change, now that expr_defer expression parsing mode latches dot as is
desired here.
Also add testing for the . case, which I should have done already back
at the time.
Jan Beulich [Fri, 10 Jan 2025 07:42:00 +0000 (08:42 +0100)]
gas: make deferred expression evaluation generally latch dot
Deferring expression evaluation is often necessary. However, the value
current_location() records typically is intended to represent the
location at the point of use of the expression, with the exception being
.eqv (or its == equivalent). Change how expr_defer behaves in this
regard, and introduce a special mode just for pseudo_set() to use.
Introduce a predicate to cover both "deferred" modes, and use it
everywhere except in current_location(), where only the new mode wants
checking for.
Tom de Vries [Fri, 10 Jan 2025 07:40:11 +0000 (08:40 +0100)]
[gdb/build, c++20] Fix build with gcc 10
With gcc 10 and -std=c++20, we run into the same problem as reported in commit 6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct").
The problem was fixed using:
...
-template<typename T, typename A = std::allocator<T>>
+template<typename T,
+ typename A
+#if __cplusplus >= 202002L
+ = std::pmr::polymorphic_allocator<T>
+#else
+ = std::allocator<T>
+#endif
+ >
...
but that doesn't work for gcc 10, because it defines __cplusplus differently:
...
$ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 201709L
$ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 202002L
...
Fix this by using the library feature test macro
__cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined
for c++20:
...
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \
| grep __cpp_lib_polymorphic_allocator
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \
| grep __cpp_lib_polymorphic_allocator
#define __cpp_lib_polymorphic_allocator 201902L
$
...
A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work
around Werror=volatile in libguile.h"). Fix this by testing for 201709L
instead.
Tested on x86_64-linux, by building gdb with
{gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}.
GDB: trad-frame: Store length of value_bytes in trad_frame_saved_reg
The goal is to ensure that it is available in frame_unwind_got_bytes () to
make sure that the provided buf isn't larger than the size of the register
being provisioned.
In the process, regcache's cached_reg_t::data also needed to be
converted to a gdb::byte_vector, so that the register contents' size can
be tracked.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Thu, 9 Jan 2025 13:32:19 +0000 (14:32 +0100)]
[gdb/tdep] Fix gdb.base/readnever.exp on s390x
On s390x-linux, I run into:
...
(gdb) backtrace
#0 0x000000000100061a in fun_three ()
#1 0x000000000100067a in fun_two ()
#2 0x000003fffdfa9470 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) FAIL: gdb.base/readnever.exp: backtrace
...
This is really due to a problem handling the fun_three frame. When generating
a backtrace from fun_two, everying looks ok:
...
$ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \
-ex "b fun_two" \
-ex run \
-ex bt
...
#0 0x0000000001000650 in fun_two ()
#1 0x00000000010006b6 in fun_one ()
#2 0x00000000010006ee in main ()
...
For reference the frame info with debug info (without -readnever) looks like this:
...
$ gdb -q -batch outputs/gdb.base/readnever/readnever \
-ex "b fun_three" \
-ex run \
-ex "info frame"
...
Stack level 0, frame at 0x3fffffff140:
pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a
called by frame at 0x3fffffff1f0
source language c.
Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c
Locals at 0x3fffffff140, Previous frame's sp in v0
...
But with -readnever, like this instead:
...
Stack level 0, frame at 0x0:
pc = 0x100061a in fun_three; saved pc = 0x100067a
called by frame at 0x3fffffff140
Arglist at 0xffffffffffffffff, args:
Locals at 0xffffffffffffffff, Previous frame's sp in r15
...
An obvious difference is the "Previous frame's sp in" v0 vs. r15.
Looking at the code:
... 0000000001000608 <fun_three>: 1000608: b3 c1 00 2b ldgr %f2,%r11 100060c: b3 c1 00 0f ldgr %f0,%r15 1000610: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) 1000616: b9 04 00 bf lgr %r11,%r15
...
it becomes clear what is going on. This is an unusual prologue.
Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack,
instead they're saved into call-clobbered floating point registers.
[ For reference, this is the prologue of fun_two:
... 0000000001000640 <fun_two>: 1000640: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) 1000646: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) 100064c: b9 04 00 bf lgr %r11,%r15
...
where the first instruction stores registers r11 to r15 to stack. ]
Gdb fails to properly analyze the prologue, which causes the problems getting
the frame info.
Fix this by:
- adding handling of the ldgr insn [1] in s390_analyze_prologue, and
- recognizing the insn as saving a register in
s390_prologue_frame_unwind_cache.
This gets us instead:
...
Stack level 0, frame at 0x0:
pc = 0x100061a in fun_three; saved pc = 0x100067a
called by frame at 0x3fffffff1f0
Arglist at 0xffffffffffffffff, args:
Locals at 0xffffffffffffffff, Previous frame's sp in f0
...
and:
...
(gdb) backtrace^M
#0 0x000000000100061a in fun_three ()^M
#1 0x000000000100067a in fun_two ()^M
#2 0x00000000010006b6 in fun_one ()^M
#3 0x00000000010006ee in main ()^M
(gdb) PASS: gdb.base/readnever.exp: backtrace
...
Tom de Vries [Thu, 9 Jan 2025 13:32:19 +0000 (14:32 +0100)]
[gdb/tdep] Use symbolic constants in s390_prologue_frame_unwind_cache
In s390_prologue_frame_unwind_cache there are two loops using a hardcoded
constant 16:
...
for (i = 0; i < 16; i++)
if (s390_register_call_saved (gdbarch, S390_R0_REGNUM + i)
...
for (i = 0; i < 16; i++)
if (s390_register_call_saved (gdbarch, S390_F0_REGNUM + i)
...
Fix this by using symbolic constants S390_NUM_GPRS and S390_NUM_FPRS instead.
gdbserver: introduce and use regcache::set_register_status
Introduce and use a setter method in regcache to set the status of a
register. There already exists get_register_status. So, it made
sense to add the setter to control access to the register_status
field.
In two places, we also do cosmetic improvements to for-loops.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Thu, 9 Jan 2025 12:14:57 +0000 (13:14 +0100)]
[gdb/testsuite] Run one more test-case with ASAN_OPTIONS=verify_asan_link_order=0
After building gdb with asan, and running test-case
gdb.trace/basic-libipa.exp, I got:
...
(gdb) run ^M
Starting program: basic-libipa ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
==7705==ASan runtime does not come first in initial library list; you should \
either link runtime to your application or manually preload it with \
LD_PRELOAD.^M
[Inferior 1 (process 7705) exited with code 01]^M
(gdb) FAIL: gdb.trace/basic-libipa.exp: runto: run to main
...
Fix this in the same way as in commit 75948417af8 ("[gdb/testsuite] Run two
test-cases with ASAN_OPTIONS=verify_asan_link_order=0").
gdbserver: dump 'xx...x' in collect_register_as_string for unavailable register
Fix 'collect_register_as_string' so that unavailable registers are
dumped as 'xx...x' instead of arbitrary values, in particular when
reporting expedited registers in a resume reply packet. This change
gives the opportunity that we can reuse 'collect_register_as_string'
in 'registers_to_string' for additional code simplification.
Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Thu, 9 Jan 2025 04:37:49 +0000 (15:07 +1030)]
Excessive gas .irpt count
There is a test in do_repeat to error on "negative" repeat counts.
Just at what value a ssize_t is negative of course depends on the
host. Change the excessive repeat count to a fixed value, 0x80000000,
ie. what would be seen as negative on a 32-bit host.
Charlie Jenkins [Tue, 7 Jan 2025 21:35:45 +0000 (13:35 -0800)]
RISC-V: Add partial instruction display tests
When objdump is specified with a stop address that ends up in the middle
of an instruction, the partial instruction is expected to be displayed.
These three tests check that the partial instruction is correctly
displayed when there are 1, 2, or 3 bytes of the instruction dumped.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Charlie Jenkins [Tue, 7 Jan 2025 21:35:44 +0000 (13:35 -0800)]
RISC-V: Fix display of partial instructions
As of commit e43d8768d909 ("RISC-V: Fix disassemble fetch fail return
value.") partial instructions are no longer displayed by objdump. While
that commit fixed the behavior of print_insn_riscv() returning the
arbitrary status value upon failure, it caused the behavior of dumping
instructions to change. Allow partial instructions to be displayed once
again and only return -1 if no part of the instruction was able to be
displayed.
Tom Tromey [Wed, 8 Jan 2025 20:05:16 +0000 (13:05 -0700)]
Rename two Ada test suite functions
I happened to notice that the Ada compiler emitted a warning when
compiling a couple of DAP tests. This wasn't intentional, and this
patch renames the functions to match the filename.
GDB, gdbserver: Convert regcache_register_size function to method
The regcache_register_size function has one implementation in GDB, and
one in gdbserver. Both of them have a gdb::checked_static_cast to their
corresponding regcache class. This can be avoided by defining a
pure virtual register_size method in the
reg_buffer_common class, which is then implemented by the reg_buffer
class in GDB, and by the regcache class in gdbserver.
Calls to the register_size () function from methods of classes in the
reg_buffer_common hierarchy need to be changed to calls to the newly
defined method, otherwise the compiler complains that a matching method
cannot be found.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3
Tom de Vries [Wed, 8 Jan 2025 15:24:11 +0000 (16:24 +0100)]
[gdb/testsuite] Check gnatmake version in gdb.ada/scalar_storage.exp
On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into:
...
(gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
get_compiler_info: gcc-14-2-0
print V_BE^M
$2 = (value => 126, another_value => 12, color => red)^M
(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE
...
The test-case contains a corresponding kfail:
...
# This requires a compiler fix that is in GCC 14.
if {[gcc_major_version] < 14} {
setup_kfail "DW_AT_endianity on enum types" *-*-*
}
...
which doesn't trigger because it checks the gcc version rather than the
gnatmake version.
Fix this by checking the gnatmake version instead.
Tom de Vries [Wed, 8 Jan 2025 15:07:08 +0000 (16:07 +0100)]
[gdb/testsuite] Require can_spawn_for_attach in gdb.base/gstack.exp
I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope
set to 1 and ran into:
...
PASS: gdb.base/gstack.exp: spawn gstack
ptrace: Operation not permitted.^M
GSTACK-END^M
PASS: gdb.base/gstack.exp: gstack exits with no error
PASS: gdb.base/gstack.exp: gstack's exit status is 0
FAIL: gdb.base/gstack.exp: got backtrace
...
Tom de Vries [Wed, 8 Jan 2025 11:48:08 +0000 (12:48 +0100)]
[gdb/testsuite] Require supports_process_record in gdb.reverse/test_ioctl_TCSETSW.exp
I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got:
...
(gdb) record full^M
Process record: the current architecture doesn't support record function.^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full
...
Tom de Vries [Wed, 8 Jan 2025 09:06:28 +0000 (10:06 +0100)]
[gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp for !supports_catch_syscall
I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got:
...
(gdb) catch syscall write^M
The feature 'catch syscall' is not supported on this architecture yet.^M
(gdb) FAIL: $exp: mode=syscall: catch syscall write
...
Fix 32085 Source file not recognized for gcc 11.4.0-compiled code
gprofng cannot read compressed section.
In the next release we plan to use libbfd everywhere instead of our ELF reader.
But in this release I use bfd_get_full_section_contents() only
when bfd_is_section_compressed() returns true.
gprofng/ChangeLog
2025-01-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/32085
* src/Elf.cc: Use bfd_get_full_section_contents to decompress a section.
* src/Elf.h: Define SEC_DECOMPRESSED.
Liwei Xu [Wed, 8 Jan 2025 03:38:48 +0000 (11:38 +0800)]
Support Intel AMX-FP8
In this patch, we will support AMX-FP8 feature. Since in the
foreseeable future, only AMX-MOVRS will also use VEX_MAP5, we
currently will not add a table of 256 entries and handle just
like MAP7.
Tom Tromey [Sun, 5 Jan 2025 22:20:50 +0000 (15:20 -0700)]
Rename two maint commands
This renames two maint commands, removing a hyphen from
"check-symtabs" and "check-psymtabs"; that is, moving them under the
existing "maint check" prefix.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Tom de Vries <tdevries@suse.de> Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Mon, 6 Jan 2025 20:34:47 +0000 (13:34 -0700)]
Fix crash in DWARF indexer
Iain pointed out a crash in the DWARF indexer when run on a certain D
program. The DWARF in this case has a nameless enum class; this
causes an assertion failure.
This patch arranges to simply ignore such types. The fact that an
enum class is nameless in this case appears to be a compiler bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518 Approved-By: Tom de Vries <tdevries@suse.de>
testsuite: adapt to new --debug command line option
Since commit "gdbserver: allow the --debug command line option to take a
value", gdbserver no longer supports
--debug
--remote-debug
--event-loop-debug.
Instead, --debug now takes a comma separated list of components.
The make check parameter GDBSERVER_DEBUG doesn't support these changes
yet. This patch fixes this, by adding the --debug gdbserver arguments,
as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for
GDBSERVER_DEBUG. Replay logging is still enabled by adding the
"replay" GDBSERVER_DEBUG argument. We can also configure "all" to
enable all of the available options.
Now, for instance, we can use it as follows:
make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
or simply
make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
Tom Tromey [Fri, 20 Dec 2024 20:16:17 +0000 (13:16 -0700)]
Clarify documentation of signal numbers
A user was confused by the meaning of signal numbers in the gdb CLI.
For instance, when using "signal 3", exactly which signal is
delivered? Is it always 3, or is it always SIGQUIT?
This patch attempts to clarify the documentation here.
projects / thirdparty / binutils-gdb.git / log
