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.
Clément Chigot [Mon, 9 Dec 2024 10:00:07 +0000 (11:00 +0100)]
ld/testsuite: move board flags to ld_link
Both CFLAGS and LDFLAGS provided by dejagnu board configuration could be
required to perform a link.
Up to now, those flags were pulled with run_cc_link_tests and
run_ld_link_exec_tests and then passed to ld_link process as arguments.
This means that calling `ld_link` outside those functions must remember
to manually pass them.
Clément Chigot [Tue, 10 Dec 2024 13:08:44 +0000 (14:08 +0100)]
ld/testsuite/lto: replace manual links by ld_link helper
Some tests are calling run_host_cmd in order to retrieve the
errors/warnings messages generated.
ld_link is also making them available through exec_output global
variable but as the advantages of taking the board configuration into
account unlike run_host_cmd.
Jan Beulich [Mon, 6 Jan 2025 15:25:17 +0000 (16:25 +0100)]
x86/APX: simplify ENQCMD[,S} opcode table entries
APX_F() makes sense to use only for dual VEX/EVEX templates; ENQCMD{,S}
are legacy encoded though in their original forms. Make the entries
match the MOVDIR{I,64B} sibling ones.
Rainer Orth [Mon, 6 Jan 2025 15:24:14 +0000 (16:24 +0100)]
Fix procfs.c compilation
procfs.c compilation is currently broken on Solaris:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2067 | wait_retval = gdb::wait (&wstat);
| ^~~~
In file included from ../gnulib/import/sys/wait.h:28,
from /usr/include/stdlib.h:16,
from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
from <command-line>:
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2154 | int temp = gdb::wait (&wstat);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2566 | gdb::wait (NULL);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
Jan Beulich [Mon, 6 Jan 2025 15:01:47 +0000 (16:01 +0100)]
x86/Intel: don't accept memory operands with J*CXZ and LOOP*
PR gas/31887
Like for, in particular, J<cc> such should be rejected. Simplify the
respective conditional in i386_intel_operand(), leveraging that
JumpAbsolute will never occur in the first template of a mnemonic-
specific group (thus making it unnecessary to exclude that one case).
At this occasion do the same simplification later in the function as
well: The resulting two operands will uniformly be invalid for all
mnemonics other than CALL and JMP (and their AT&T counterparts, which
we've been wrongly accepting in Intel syntax) anyway.
Jan Beulich [Mon, 6 Jan 2025 15:01:07 +0000 (16:01 +0100)]
gas: special-case division / modulo by ±1
Dividing the largest possible negative value by -1 generally is UB, for
the result not being representable at least in commonly used binary
notation. This UB on x86, for example, is a Floating Point Exception on
Linux, i.e. resulting in an internal error (albeit only when
sizeof(valueT) == sizeof(void *); the library routine otherwise involved
apparently deals with the inputs quite okay).
Leave original values unaltered for division by 1; this may matter down
the road, in case we start including X_unsigned and X_extrabit in
arithmetic. For the same reason treat modulo by 1 the same as modulo by
-1.
The quad and octa tests have more relaxed expecations than intended, for
X_unsigned and X_extrabit not being taken into account [yet]. The upper
halves can wrongly end up as all ones (for .octa, when !BFD64, even the
upper three quarters). Yet it makes little sense to address this just
for div/mod by ±1. quad-div2 is yet more special, to cover for most
32-bit targets being unable to deal with forward-ref expressions in
.quad even when BFD64; even ones being able to (like x86) then still
don't get the values right.
Tom Tromey [Tue, 17 Dec 2024 19:35:44 +0000 (12:35 -0700)]
Don't lex floating-point number in Rust field expression
Consider this Rust tuple:
let tuple_tuple = ((23i32, 24i32), 25i32);
Here, the value is a tuple whose first element is also a tuple.
You should be able to print this with:
(gdb) print tuple_tuple.0.1
However, currently the Rust lexer sees "0.1" as a floating-point
number.
This patch fixes the problem by introducing a special case in the
lexer: when parsing a field expression, the parser informs the lexer
that a number should be handled as a decimal integer only.
This change then lets us remove the decimal integer special case from
lex_number.
v2: I realized that the other DECIMAL_INTEGER cases aren't needed any
more.
Tom de Vries [Mon, 6 Jan 2025 08:53:26 +0000 (09:53 +0100)]
[gdb/build] Use const_cast in fd_copy
Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did:
...
fd_copy (fd_set *dst, const fd_set *src, int n)
{
FD_ZERO (dst);
for (int i = 0; i < n; ++i)
- if (FD_ISSET (i, src))
+ if (FD_ISSET (i, (fd_set *)src))
...
but according to [1] only const_cast may be used to cast away constness.
Alan Modra [Sun, 5 Jan 2025 11:14:06 +0000 (21:44 +1030)]
ar and foreign object files
ar is supposed to make archives containing any sort of file, and it
generally does that. It also tries to make archives suited to target
object files stored. Some targets have peculiar archives.
In one particular case we get into trouble trying to suit archives to
object files: where the target object file is recognised but that
target doesn't happen to support archives, and the default target has
a special archive format. For example, we'll get failures on
rs6000-aix if trying to add tekhex objects to a new archive. What
happens in that the tekhex object is recognised and its target vector
used to create an empty archive, ie. with _bfd_generic_mkarchive and
_bfd_write_archive_contents. An attempt is then made to open the
newly created archive. The tekhex target vector does not have a
check_format function to recognise generic archives, nor as it happens
do any of the xcoff or other targets built for rs6000-aix.
It seems to me the simplest fix is to not use any target vector to
create archives where that vector can't also recognise them. That's
what this patch does, and to reinforce that I've removed target vector
support for creating empty archives from such targets.
bfd/
* i386msdos.c (i386_msdos_vec): Remove support for creating
empty archives.
* ihex.c (ihex_vec): Likewise.
* srec.c (srec_vec, symbolsrec_vec): Likewise.
* tekhex.c (tekhex_vec): Likewise.
* wasm-module.c (wasm_vec): Likewise.
* ptrace-core.c (core_ptrace_vec): Tidy.
* targets.c (bfd_target_supports_archives): New inline function.
* bfd-in2.h: Regenerate.
binutils/
* ar.c (open_inarch): Don't select a target from the first
object file that can't read archives. Set output_filename
earlier.
* testsuite/binutils-all/ar.exp (thin_archive_with_nested):
Don't repeat --thin test using T.
(foreign_object): New test.
* testsuite/binutils-all/tek1.obj,
* testsuite/binutils-all/tek2.obj: New files.
Tom Tromey [Thu, 19 Dec 2024 01:49:45 +0000 (18:49 -0700)]
Fix latent bug in Ada import symbol handling
The code in dwarf2/read.c:new_symbol that handles Ada 'import' symbols
has a bug. It uses the current scope, which by default this is the
file scope -- even for a global symbol like:
This disagrees with the scope computed by the DWARF indexer.
Now, IMO new_symbol and its various weirdness really has to go. And,
ideally, this information would come from the indexer rather than
perhaps being erroneously recomputed. But meanwhile, this patch fixes
the issue at hand.
This came up while working on another change that exposes the bug.
A recent discussion about what commands are allowed during
gdb.Breakpoint.stop, made me wonder if there would be less restrictions if
we'd do those commands as part of a breakpoint command list instead.
Attribute gdb.Breakpoint.commands is a string with gdb commands, so I
tried implementing a new class PyCommandsBreakpoint, derived from
gdb.Breakpoint, that supports a py_commands method.
My original idea was to forbid setting PyCommandsBreakpoint.commands, and do:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
gdb.execute("continue")
...
but as it turns out 'gdb.execute("continue")' does not behave the same way as
continue. I've filed PR python/32454 about this.
So the unsatisfactory solution is to first execute
PyCommandsBreakpoint.py_commands:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
...
and then:
...
self.commands = "continue"
...
I was hoping for a better outcome, but having done the work of writing this, I
suppose it has use as a test-case, perhaps also as an example of how to work
around PR python/32454.
Tom de Vries [Sat, 4 Jan 2025 10:31:02 +0000 (11:31 +0100)]
[gdb/tdep] Fix gdb.base/finish-pretty.exp on s390x
On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into:
...
(gdb) finish
Run till exit from #0 foo () at finish-pretty.c:28
main () at finish-pretty.c:40
40 return v.a + v.b;
Value returned has type: struct s. Cannot determine contents
(gdb) FAIL: $exp: finish foo prettyprinted function result
...
The function being finished is foo, which returns a value of type struct s.
The ABI [1] specifies:
- that the value is returned in a storage buffer allocated by the caller, and
- that the address of this buffer is passed as a hidden argument in r2.
GDB fails to print the value when finishing foo, because it doesn't know the
address of the buffer.
Implement the gdbarch_get_return_buf_addr hook for s390x to fix this.
This is based on ppc_sysv_get_return_buf_addr, the only other implementation
of gdbarch_get_return_buf_addr. For readability I've factored out
dwarf_reg_on_entry.
There is one difference with ppc_sysv_get_return_buf_addr: only
NO_ENTRY_VALUE_ERROR is caught. If this patch is approved, I intend to submit
a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well.
The hook is not guaranteed to work, because it attempts to get the value r2
had at function entry.
The hook can be called after function entry, and the ABI doesn't guarantee
that r2 is the same throughout the function.
Using -fvar-tracking adds debug information, which allows the hook to succeed
more often, and indeed after adding this to the test-case, it passes.
Running selftest help_doc_invariants.
help doc broken invariant: command 'signal-event' help doc has over-long line
Self test failed: self-test failed at unittests/command-def-selftests.c:121
The reason is that doc string of 'signal-event' doesn't have
newlines at end of its line. Fix by adding newlines.
Tom de Vries [Sat, 4 Jan 2025 09:19:37 +0000 (10:19 +0100)]
[gdb/cli] Warn about forced return from signal trampoline
The Linaro CI reported a regression on arm-linux in test-case
gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply
workaround for PR gas/31115 a bit more") [1]:
...
(gdb) return^M
Make __default_sa_restorer return now? (y or n) n^M
Not confirmed^M
(gdb) FAIL: $exp: return from handleri: \
leave signal trampoline (got interactive prompt)
...
After installing package glibc-debuginfo and adding --with-separate-debug-dir
to the configure flags, I managed to reproduce the FAIL.
The regression seems to be a progression in the sense that the function name
for the signal trampoline is found.
After reading up on the signal trampoline [2] and the return command [3], my
understanding is that forced returning from the signal trampoline is
potentially unsafe, given that for instance the process signal mask won't be
restored.
Fix this by:
- rather than using the name, using "signal trampoline" in the query, and
- adding a warning about returning from a signal trampoline,
giving us:
...
(gdb) return^M
warning: Returning from signal trampoline does not fully restore pre-signal \
state, such as process signal mask.^M
Make signal trampoline return now? (y or n) y^M
87 dummy = 0; dummy = 0; while (!done);^M
(gdb) PASS: $exp: return from handleri: leave signal trampoline (in main)
...
Alan Modra [Sat, 4 Jan 2025 03:09:20 +0000 (13:39 +1030)]
ELF sec_info memory leaks
Use the bfd's objalloc memory so we don't need to free anything
attached to elf_section_data sec_info. Other uses of sec_info that
need to allocate memory already use bfd_alloc.
Alan Modra [Sat, 4 Jan 2025 06:27:48 +0000 (16:57 +1030)]
_bfd_write_ar_hdr
This has been broken since commit 8f95b6e44955 in 2010, and apparently
nobody has noticed. How we write archive headers depends on the
archive, not the contents.
Fangrui Song [Sun, 29 Dec 2024 22:57:44 +0000 (14:57 -0800)]
skip -gfile: call fnmatch without FNM_FILE_NAME
fnmatch is called with the FNM_FILE_NAME flag so that `skip -gfi /usr/*`
doesn't match /usr/include/*. This makes the file matching feature not
useful for STL headers that reside in multiple directories. In
addition, the user cannot use a single `*` to match multiple leading
path components.
Let's drop the FNM_FILE_NAME flag and remove the assertion from
gdb_filename_fnmatch (originally for the auto-load feature).
Alan Modra [Fri, 3 Jan 2025 23:10:21 +0000 (09:40 +1030)]
bfd_set_input_error
My recent change to closing archives showed some problems with the way
we stash errors for archive elements. The most obvious thing found
by oss-fuzz, is that if output archive elements are closed during
bfd_close of an archive, then we can't access the element filename
when printing the element. So change bfd_set_input_error to stash the
entire error message instead of input bfd and input error.
H.J. Lu [Thu, 2 Jan 2025 22:25:57 +0000 (06:25 +0800)]
nesting[123].d: Replace Sone with Some in comment
* testsuite/gas/macros/nesting1.d: Replace Sone with Some in
comment.
* testsuite/gas/macros/nesting2.d: Likewise.
* testsuite/gas/macros/nesting3.d: Likewise.
H.J. Lu [Wed, 1 Jan 2025 22:09:30 +0000 (06:09 +0800)]
gas: Revert PR 32391 related commits to fix 3 regressions
9f2e3c21f65 Fix the handling or arguments and macro pseudo-variables inside nested assembler macros.
introduced 3 regressions of PR gas/32484, PR gas/32486 and PR gas/32487.
Revert all PR 32391 related commits and add tests for PR gas/32484,
PR gas/32486, PR gas/32487.
projects / thirdparty / binutils-gdb.git / log
