Simon Marchi [Tue, 30 Jul 2024 19:24:58 +0000 (19:24 +0000)]
gdb: don't call macro_bcache with nullptr
Since commit b1da98a74656 ("gdb: remove use of alloca in
new_macro_definition"), if cached_argv is empty, we call macro_bcache
with a nullptr data. This ends up caught by UBSan deep down in the
bcache code:
$ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow
Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
/home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null
The backtrace:
#1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750
#2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195
#3 0x0000555564b49222 in gdb::bcache::insert<char const*, void> (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158
#4 0x0000555564b481fa in macro_bcache<char const*> (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117
#5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573
#6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777
#7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816
#8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203
This can be reproduced by running gdb.base/macscp.exp. Avoid calling
macro_bcache if the macro doesn't have any arguments.
gprofng: 32018 Compilation of binutils 2.43 failed on CentOS 6
strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7.
In this case, we may not use our CALL_UTIL macro for strchr.
Use __collector_strchr instead of "CALL_UTIL (strchr)".
gprofng/ChangeLog
2024-07-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32018
* libcollector/hwprofile.c (open_experiment): Use __collector_strchr.
Tom de Vries [Tue, 30 Jul 2024 14:56:31 +0000 (16:56 +0200)]
[gdb/symtab] Emit malformed macro definition complaint once
Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
.debug_macro section.
For one malformed macro definition, I get two identical complaints:
...
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
...
Fix this by bailing out after the first one.
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Simon Marchi [Wed, 24 Jul 2024 19:07:14 +0000 (15:07 -0400)]
gdb: use std::string vector for macro definition
Use std::vector<std::string> when defining macros, to avoid the manual
memory management.
With the use of std::vector, the separate `int argc` parameter is no
longer needed, we can use the size of the vector instead. However, for
some functions, this parameter had a dual function. For object-like
macros, it was interpreted as a `macro_special_kind` enum. For these
functions, remove `argc`, but add a new `special_kind` parameter.
Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5 Approved-By: Tom de Vries <tdevries@suse.de>
It also tests the gcore script being run without its accessible
terminal.
This test was written by Jan Kratochvil a long time ago. I modernized
the test making it use various procs from lib/gdb.exp, reorganizing it
and added some comments.
Modify the gcore script to make it possible to pass the --data-directory to
it. This prevents a lot of these warnings:
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
Tested by using make check-all-boards.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom de Vries [Mon, 29 Jul 2024 13:42:28 +0000 (15:42 +0200)]
[gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0
When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we
run into:
...
(gdb) save gdb-index index_1^M
Error while writing index for `xgdb': No debugging symbols^M
(gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file
...
Fix this by instead emitting an unsupported, and bailing out.
Tom de Vries [Mon, 29 Jul 2024 12:05:52 +0000 (14:05 +0200)]
[gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.exp
When running test-case gdb.threads/leader-exit-attach.exp with target board
native-extended-gdbserver I run into:
...
(gdb) KFAIL: $exp: attach (PRMS: gdb/31555)
print $_inferior_thread_count^M
$1 = 0^M
(gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554)
...
The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc
("Fix "attach" failure handling with GDBserver"), and consequently the PR is
closed.
Tom de Vries [Mon, 29 Jul 2024 12:05:52 +0000 (14:05 +0200)]
[gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1
With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into:
...
(gdb) attach 18591^M
Attaching to program: leader-exit-attach, process 18591^M
warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555)
^M
ptrace: Operation not permitted.^M
(gdb) FAIL: $exp: get valueof "$_inferior_thread_count"
...
The problem is that the gdb_test_multiple in the test-case doesn't consume the
prompt in all clauses:
...
gdb_test_multiple "attach $testpid" "attach" {
-re "Attaching to process $testpid failed.*" {
# GNU/Linux gdbserver. Linux ptrace does not let you attach
# to zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "warning: process $testpid is a zombie - the process has already terminated.*" {
# Native GNU/Linux. Linux ptrace does not let you attach to
# zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
pass $gdb_test_name
set attached 1
}
}
...
Fix this by using -wrap in the first two clauses.
While we're at it, also use -wrap in the third clause.
Alan Modra [Fri, 26 Jul 2024 23:43:27 +0000 (09:13 +0930)]
Fixes to "PR 31728 testcases"
This brings us down to just these fails for the set of targets I
usually test when making testsuite changes.
aarch64-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-ld
arm-pe +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool
arm-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool
The aarch64 one is likely due to the target missing support somewhere.
It is fairly new, I haven't investigated. The arm-pe fails are due to
arm-pe being a target that adds underscores to symbol names (see
config.bfd) whereas dlltool thinks it does not (see
dlltool.c:asm_prefix). arm-wince-pe on the other hand doesn't add
underscores. I would guess the right fix for dlltool is to get this
symbol info from bfd using bfd_get_target_info.
Note I'm not very happy about the creative use of ld_after_inputfile
in symbols-ordinals-hints-imports-ld.d, which is likely to break with
some future run_dump_test change.
Alan Modra [Mon, 29 Jul 2024 04:55:07 +0000 (14:25 +0930)]
PR32032 dwp segfaults on hello world binary
Fixing the segfault is easy with this bandaid, but further work is
needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header.
At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id.
PR 32032
* dwp.cc (Dwp_output_file::finalize): Return immediately on
no output file.
Andrew Burgess [Mon, 3 Jun 2024 12:56:54 +0000 (13:56 +0100)]
gdb/testsuite: track if a caching proc calls gdb_exit or not
After a recent patch review I asked myself why can_spawn_for_attach
exists. This proc currently does some checks, and then calls
can_spawn_for_attach_1 which is an actual caching proc.
The answer is that can_spawn_for_attach exists in order to call
gdb_exit the first time can_spawn_for_attach is called within any test
script.
The reason this is useful is that can_spawn_for_attach_1 calls
gdb_exit. If the user calls can_spawn_for_attach_1 directly then a
problem might exist. Imagine a test written like this:
gdb_start
if { [can_spawn_for_attach_1] } {
... do stuff that assumes GDB is running ...
}
If this test is NOT the first test run, and if an earlier test calls
can_spawn_for_attach_1, then when the above test is run the
can_spawn_for_attach_1 call will return the cached value and gdb_exit
will not be called.
But, if the above test IS the first test run then
can_spawn_for_attach_1 will not return the cached value, but will
instead compute the cached value, a process that ends up calling
gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited
and the test might fail if it is written assuming that GDB is
running.
So can_spawn_for_attach was added which ensures that we _always_ call
gdb_exit the first time can_spawn_for_attach is called within a single
test script, this ensures that in the above case, even if the above is
not the first test script run, gdb_exit will still be called. This
ensures consistent behaviour and avoids some hidden bugs in the
testsuite.
The split between can_spawn_for_attach and can_spawn_for_attach_1 was
introduced in this commit:
[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach
However, I observe that can_spawn_for_attach is not the only caching
proc that calls gdb_exit. Why does can_spawn_for_attach get special
treatment when surely the same issue exists for any other caching proc
that calls gdb_exit?
I think a better solution is to move the logic from
can_spawn_for_attach into cache.exp and generalise it so that it
applies to all caching procs.
This commit does this by:
1. When the underlying caching proc is executed we track calls to
gdb_exit. If a caching proc calls gdb_exit then this information
is stored in gdb_data_cache (using a ',exit' suffix), and also
written to the cache file if appropriate.
2. When a cached value is returned from gdb_do_cache, if the
underlying proc would have called gdb_exit, and if this is the
first use of the caching proc in this test script, then we call
gdb_exit.
When storing the ',exit' value into the on-disk cache file, the flag
value is stored on a second line. Currently every cached value only
occupies a single line, and a check is added to ensure this remains
true in the future.
To track calls to gdb_exit I eventually settled on using TCL's trace
mechanism. We already make use of this in lib/gdb.exp so I figure
this is OK to use. This should be fine, so long as non of the caching
procs use 'with_override' to replace gdb_exit, or do any other proc
replacement to change gdb_exit, however, I think that is pretty
unlikely.
One issue did come up in testing, a FAIL in gdb.base/break-interp.exp,
prior to this commit can_spawn_for_attach would call gdb_exit before
calling the underlying caching proc. After this call we call gdb_exit
after calling the caching proc.
The underlying caching proc relies on gdb_exit having been called. To
resolve this issue I just added a call to gdb_exit into
can_spawn_for_attach.
With this done can_spawn_for_attach_1 can be renamed to
can_spawn_for_attach, and the existing can_spawn_for_attach can be
deleted.
In the next commit I want to add more information to
gdb_data_cache (see lib/cache.exp). Specifically I want to track if
the underlying function of a caching proc calls gdb_exit or not.
Currently gdb_data_cache is an associative array, the keys of which
are the name of the caching proc.
In this commit I add a ',value' suffix to the gdb_data_cache keys. In
the next commit I'll add additional entries with a different suffix.
There should be no noticable changes after this commit, this is just a
restructuring.
Tom de Vries [Sat, 27 Jul 2024 08:05:20 +0000 (10:05 +0200)]
[gdb/tdep] Fix arm thumb2 hw breakpoint
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
This may or may not be a kernel bug.
Work around this by first using an inoffensive address bpts[i].address & ~0x7.
Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on
target board native-gdbserver/mthumb.
While we're at it:
- use arm_hwbp_control_is_initialized in
arm_linux_nat_target::low_prepare_to_resume,
- handle the !arm_hwbp_control_is_initialized case explicitly,
- add missing '_()' in arm_target::low_prepare_to_resume,
- make error messages identical between arm_target::low_prepare_to_resume and
arm_linux_nat_target::low_prepare_to_resume,
- factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to
make the implementation more readable.
Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in
gdb.base/hbreak.exp") by simply reverting the commit.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
YunQiang Su [Fri, 26 Jul 2024 17:01:09 +0000 (18:01 +0100)]
microMIPS: Add MT ASE instruction set support
Add the MT ASE instruction operand types and encodings to the microMIPS
opcode table and enable the assembly of these instructions in GAS from
MIPSr2 onwards. Update the binutils and GAS testsuites accordingly.
References:
"MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for
the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number:
MD00768, Revision 1.12, July 16, 2013
Co-Authored-By: Maciej W. Rozycki <macro@redhat.com>
That the test gdb.base/build-id-seqno.exp I added recently was FAILing
when using Clang as the compiler.
The problem was that I had failed to add 'build-id' as a compile
option in the call to build_executable within the test script. For
GCC this is fine as build-ids are included by default. For Clang
though this meant the build-id was not included and the test would
fail.
So I added build-id to the compiler options.... and the test still
didn't pass! Now the test fails to compile and I see this error from
the compiler:
It turns out that the build-id compile option causes our gdb.exp to
add the '-Wl,--build-id' option into the compiler flags, which means
its used when building the object file AND during the final link.
However this option is unnecessary when creating the object file and
Clang warns about this, which causes the build to fail.
The solution is to change gdb.exp, instead of adding the build-id
flags like this:
Now the flag is only appended during the link phase and Clang is
happy. The gdb.base/build-id-seqno.exp test now passes with Clang.
The same problem (adding to additional_flags instead of ldflags)
exists for the no-build-id compile option, so I've fixed that too.
While investigating this I also spotted two test scripts,
gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were
setting ldflag directly rather than using the build-id compile option
so I've updated these two tests to use the compile option which I
think is neater.
I've checked that all these tests still pass with both GCC and Clang.
There should be no changes in what is actually tested after this
commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Fri, 26 Jul 2024 06:00:42 +0000 (08:00 +0200)]
gas: drop scrubber state -2
Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring
that we wouldn't get bogus state transitions: For example, when we're in
states 0 or 1, a comment should be no different from whitespace
encountered in those states. Plus for e.g. x86 this results in such
comments now truly being converted to a blank, as mandated by
documentation. Both aspects apparently were a result of blindly (and
wrongly) moving to state 3 _before_ consuming the "ungot" blank.
Also amend a related comment elsewhere.
In the new testcase the .irp is to make visible in the listing all the
whitespace that the scrubber inserts / leaves in place.
Jan Beulich [Fri, 26 Jul 2024 05:59:53 +0000 (07:59 +0200)]
x86: accept whitespace around prefix separator
... and prediction suffix comma. Other than documented /**/ comments
currently aren't really converted to a single space, at least not for
x86 in its most common configurations. That'll be fixed subsequently, at
which point blanks may appear where so far none were expected.
Furthermore not permitting blanks around these separators wasn't quite
logical anyway - such constructs are composite ones, and hence
components ought to have been permitted to be separated by whitespace
from the very beginning. Furthermore note how, due to the scrubber being
overly aggressive in removing whitespace, some similar construct with a
prefix were already accepted.
Note how certain other checks in parse_insn() can be simplified as a
result.
While there for the prediction suffix also make checks case-insensitive
and check for a proper trailing separator.
Alan Modra [Fri, 26 Jul 2024 05:40:56 +0000 (15:10 +0930)]
Remove srcdir from x86 testcase "source:" lines
It's wrong to have ${srcdir} in run_dump_test "source:" lines, as
run_dump_test adds $srcdir/$subdir/ to the line passed to the shell
except when the source path starts with "./". The tests work
currently because the shell expands ${srcdir} to an empty string.
Alan Modra [Thu, 25 Jul 2024 23:19:48 +0000 (08:49 +0930)]
ARM print_insn_mve assertion
This corrects objdump -d -m armv8.1-m.main output for a testcase found
by oss-fuzz, .inst 0xee2fee79, which hits an assertion.
Obviously the switch case constants should be binary, not hex.
Correcting that is enough to cure this assertion, but I don't see any
point in singling out the invalid case 0b10. In fact, it is just plain
wrong to print "undefined instruction: size equals zero undefined
instruction: size equals two".
I also don't see the need for defensive programming here as is done
elsewhere in checking that "value" is in range before indexing
mve_vec_sizename. There is exactly one MVE_VSHLL_T2 entry in
mve_opcodes. It is easy to verify that "value" is only two bits.
H.J. Lu [Wed, 24 Jul 2024 06:39:50 +0000 (23:39 -0700)]
x86: Improve TLS transition error check
Provide detailed TLS transition errors when unsupported instructions are
used. Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as
R_X86_64_GOTTPOFF when performing TLS transition.
bfd/
PR ld/32017
* elf32-i386.c (elf_i386_check_tls_transition): Return different
enums for different errors.
(elf_i386_tls_transition): Change argument from r_symndx to sym.
Call _bfd_x86_elf_link_report_tls_transition_error to report TLS
transition errors.
(elf_i386_scan_relocs): Pass isym instead of r_symndx to
elf_i386_tls_transition.
(elf_i386_relocate_section): Pass sym instead of r_symndx to
elf_i386_tls_transition.
* elf64-x86-64.c (elf_x86_64_check_tls_transition): Return
different enums for different errors.
(elf_x86_64_tls_transition): Change argument from r_symndx to sym.
Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as
R_X86_64_GOTTPOFF. Call
_bfd_x86_elf_link_report_tls_transition_error to report TLS
transition errors.
(elf_x86_64_scan_relocs): Pass isym instead of r_symndx to
elf_x86_64_tls_transition.
(elf_x86_64_relocate_section): Pass sym instead of r_symndx to
elf_x86_64_tls_transition.
* elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): New.
* elfxx-x86.h (elf_x86_tls_error_type): Likewise.
(_bfd_x86_elf_link_report_tls_transition_error): Likewise.
Tom de Vries [Wed, 24 Jul 2024 14:32:35 +0000 (16:32 +0200)]
[gdb/exp] Fix ptype $_creal/$_cimag
Consider test.c, compiled with -g:
...
__complex__ float cf = 1 + 2i;
int main (void) { return 0; }
...
The values of cf and its components are:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) p cf
$1 = 1 + 2i
(gdb) p $_creal(cf)
$2 = 1
(gdb) p $_cimag(cf)
$3 = 2
...
and their respective types are:
...
(gdb) ptype $1
type = complex float
(gdb) ptype $2
type = float
(gdb) ptype $3
type = float
...
Now let's try that again, using ptype directly:
...
(gdb) ptype cf
type = complex float
(gdb) ptype $_creal(cf)
type = int
(gdb) ptype $_cimag(cf)
type = int
...
The last two types should have been float, not int.
Fix this by extending the internal function handlers creal_internal_fn and
cimag_internal_fn with the noside parameter, such that we get instead:
...
(gdb) ptype $_creal(cf)
type = float
(gdb) ptype $_cimag(cf)
type = float
...
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR exp/31816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816
Tom de Vries [Wed, 24 Jul 2024 14:32:35 +0000 (16:32 +0200)]
[gdb/exp] Allow internal function to indicate return type
Currently an internal function handler has this prototype:
...
struct value *handler (struct gdbarch *gdbarch,
const struct language_defn *language,
void *cookie, int argc, struct value **argv);
...
Also allow an internal function with a handler with an additional
"enum noside noside" parameter:
...
struct value *handler (struct gdbarch *gdbarch,
const struct language_defn *language, void *cookie,
int argc, struct value **argv, enum noside noside);
...
In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's
expected to return some value with the correct return type.
At least, provided it can do so without side effects, otherwise it should
throw an error.
Sometimes, if I'm testing on a loaded machine, the
gdb.gdb/index-file.exp test will timeout during some early steps,
which then cases a TCL error to be thrown later in the test script.
Dejagnu then reports this error once the test run has completed, which
can be pretty noisy, and isn't really very helpful.
The underlying problem is that if GDB takes too long to load the
executable (which is GDB itself in this test) then GDB will still be
busy loading the executable when dejagnu moves on and call
gdb_get_worker_threads. The gdb_get_worker_threads call itself times
out as GDB is _still_ busy loading the executable, and so
gdb_get_worker_threads returns the string "UNKNOWN".
Later we try to perform arithmetic on the worker thread count, which
results in errors when we try to do 'UNKNOWN / 2'.
I propose that after calling gdb_get_worker_threads, we check if the
result was UNKNOWN. If it was then we should report an UNRESOLVED and
abandon the test, this avoids the later TCL errors.
Tom de Vries [Wed, 24 Jul 2024 12:56:56 +0000 (14:56 +0200)]
[gdb/testsuite] Handle address class annotation for s390x in some test-cases
On s390x-linux, I ran into:
...
(gdb) ptype crash^M
type = class crash {^M
^M
public:^M
crash(int (class {...}::*)(class {...} * const @mode32));^M
}^M
(gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash
...
The problem is that the test-case doesn't expect the address class annotation
@mode32.
The test-case uses a .S file, with the address size hard-coded to 4 bytes, and
that's something that is annotated with @mode32 on s390x (which uses 8 byte
addresses).
Fix this by allowing the annotation in the regexp.
Tom Tromey [Tue, 2 Jul 2024 16:43:51 +0000 (10:43 -0600)]
Add returnValue scope to DAP
The DAP spec recently changed to add a new scope for the return value
from a "stepOut" request. This new scope uses the "returnValue"
presentation hint. See:
Tom Tromey [Tue, 23 Jul 2024 16:01:39 +0000 (10:01 -0600)]
Refine the 'define' documentation
A while ago, an AdaCore user reported some difficulties with the
'define' command. While some of these difficulties are intrinsic, or
at least difficult to change, it seemed sensible to document a couple
of the typical problems -- and to make the text describing argument
substitution a bit more prominent.
Simon Marchi [Mon, 22 Jul 2024 14:42:49 +0000 (10:42 -0400)]
gdb/solib-frv: move lm_info object to solib
I noticed that the lm_info_frv objects created in frv_current_sos are
never moved to the solib object. This bug was introduced in 8971d2788e
("gdb: link so_list using intrusive_list"), which mistakenly removed the
line
sop->lm_info = std::move (li);
... probably due so a bad merge conflict resolution.
Re-add this line.
If merged in master, I would cherry-pick this to gdb-15-branch.
Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Tue, 23 Jul 2024 12:38:16 +0000 (14:38 +0200)]
[gdb/testsuite] Add xfail in gdb.base/hbreak.exp
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
I'm not sure if this is simply unsupported or if there's a kernel bug of some
sort, but I don't see what gdb can do about this.
Tom de Vries [Tue, 23 Jul 2024 12:27:36 +0000 (14:27 +0200)]
[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linux
On arm-linux, I run into:
...
PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the test-case expects a level 3 frame, but there is none.
This can be reproduced using cli bt:
...
$ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "b task_switch.break_me" \
-ex run \
-ex bt
Breakpoint 1 at 0x34b4: file task_switch.adb, line 57.
Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \
at task_switch.adb:57
57 null;
#0 task_switch.break_me () at task_switch.adb:57
#1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51
#2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
The purpose of the test-case is printing the frame at level 1, so I don't
think we should bother about the presence of the frame at level 3.
Fix this by allowing the backtrace to stop at level 2.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
The comment relates to how 'E.msg' style remote replies are not
supported by every packet, but after the above commit they are
supported in all cases (that call packet_check_result), and the
comment should have been removed.
Alan Modra [Sun, 21 Jul 2024 11:33:22 +0000 (21:03 +0930)]
Don't trim trailing newline in run_host_cmd
Testcases like ld-elf/pr19719a.c that
printf ("PASS\n");
on success ought to see the whole output for "string match".
Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last
newline to match. For most of the testsuite it doesn't matter whether
the trailing newline is present or not, and there are only a few cases
where we need to remove it.
* testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away
output trailing newline. Do string trim for gcc/ld version checks.
* testsuite/config/default.exp (plug_so): Do string trim output of
run_host_cmd.
* testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust
string match to include trailing newline.
* testsuite/ld-i386/i386.exp (undefined_weak): Likewise.
* testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise.
* testsuite/ld-plugin/libdep.exp (run_test): Likewise.
* testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise.
* testsuite/ld-pe/pdb-strings.d,
* testsuite/ld-pe/pdb-syms1-globals.d,
* testsuite/ld-pe/pdb-syms1-records.d,
* testsuite/ld-pe/pdb-syms1-symbols1.d,
* testsuite/ld-pe/pdb-syms1-symbols2.d,
* testsuite/ld-pe/pdb-syms2-symbols1.d,
* testsuite/ld-pe/pdb-types1-hashlist.d,
* testsuite/ld-pe/pdb-types1-skiplist.d,
* testsuite/ld-pe/pdb-types1-typelist.d,
* testsuite/ld-pe/pdb-types2-hashlist.d,
* testsuite/ld-pe/pdb-types2-skiplist.d,
* testsuite/ld-pe/pdb-types2-typelist.d,
* testsuite/ld-pe/pdb-types3-hashlist.d,
* testsuite/ld-pe/pdb-types3-skiplist.d,
* testsuite/ld-pe/pdb-types3-typelist.d,
* testsuite/ld-pe/pdb1-publics.d,
* testsuite/ld-pe/pdb1-sym-record.d,
* testsuite/ld-pe/pdb2-section-contrib.d,
* testsuite/ld-pe/pdb3-c13-info1.d,
* testsuite/ld-pe/pdb3-c13-info2.d,
* testsuite/ld-pe/pdb3-source-info.d: Add trailing newline.
Tom de Vries [Sun, 21 Jul 2024 08:03:09 +0000 (10:03 +0200)]
[gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.exp
When running test-case gdb.dap/rust-slices.exp on aarch64-linux
(debian 12/bookworm), I run into:
...
{"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success
FAIL: gdb.dap/rust-slices.exp: three scopes
PASS: gdb.dap/rust-slices.exp: scope is locals
PASS: gdb.dap/rust-slices.exp: locals presentation hint
PASS: gdb.dap/rust-slices.exp: three vars in scope
...
The test-case expects three scopes due to a rust compiler issue:
...
# There are three scopes because an artificial symbol ends up in the
# DWARF. See https://github.com/rust-lang/rust/issues/125126.
gdb_assert {[llength $scopes] == 3} "three scopes"
...
but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't
have this issue.
Fix this by allowing two or three scopes, and changing the test name to
"two scopes".
Tested on aarch64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/31983
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983
Mark Harmstone [Sat, 13 Jul 2024 14:30:46 +0000 (15:30 +0100)]
ld/testsuite: add missing definition to PDB test
The file pdb-syms1a.s was missing a definition for T_VOID, which was
causing some types not to be deduplicated. It also meant that the test
couldn't be run against LLVM's lld, which throws an error for this.
This particular test only tests the symbols stream, not the types
stream, which is why the deduplication doesn't result in a change in the
file size.
Mark Harmstone [Sat, 13 Jul 2024 14:36:34 +0000 (15:36 +0100)]
ld/PDB: use correct hashing algorithm in add_globals_ref
add_globals_ref was hashing using CRC32 rather than the hashing
algorithm used for symbols, which meant that windbg was unable to put
breakpoints against unmangled names.
The tracepoint_probe_create_sals_from_location_spec function just
forwards all its arguments to
bkpt_probe_create_sals_from_location_spec, and is only used in one
place.
Lets delete tracepoint_probe_create_sals_from_location_spec and
replace it with bkpt_probe_create_sals_from_location_spec.
There should be no user visible changes after this commit.
Andrew Burgess [Fri, 14 Apr 2023 13:45:38 +0000 (14:45 +0100)]
gdb: remove breakpoint_re_set_one
During a later patch I wanted to reset a single breakpoint, so I
called breakpoint_re_set_one. However, this is not the right thing to
do. If we look at breakpoint_re_set then we see that there's a whole
bunch of state that needs to be preserved prior to calling
breakpoint_re_set_one, and after calling breakpoint_re_set_one we
still need to call update_global_location_list.
I could just update the comment on breakpoint_re_set_one to make it
clearer how the function should be used -- or more likely to warn that
the function should only be used as a helper from breakpoint_re_set.
However, breakpoint_re_set_one is only 3 lines long. So I figure it
might actually be easier to just fold breakpoint_re_set_one into
breakpoint_re_set, then there's no risk of accidentally calling
breakpoint_re_set_one when we shouldn't.
There should be no user visible changes after this commit.
Andrew Burgess [Thu, 13 Apr 2023 14:12:17 +0000 (15:12 +0100)]
gdb: don't display inferior list for pending breakpoints
I noticed that in the 'info breakpoints' output, GDB sometimes prints
the inferior list for pending breakpoints, this doesn't seem right to
me. A pending breakpoint has no locations (at least, as far as we
display things in the 'info breakpoints' output), so including an
inferior list seems odd.
Here's what I see right now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo inf 1
(gdb)
It's the 'inf 1' at the end of the line that I'm objecting too.
To trigger this behaviour we need to be in a multi-inferior debug
session. The breakpoint must have been non-pending at some point in
the past, and so have a location assigned to it.
The breakpoint becomes pending again as a result of a shared library
being unloaded. When this happens the location itself is marked
pending (via bp_location::shlib_disabled).
In print_one_breakpoint_location, in order to print the inferior list
we check that the breakpoint has a location, and that we have multiple
inferiors, but we don't check if the location itself is pending.
This commit adds that check, which means the output is now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo
(gdb)
Which I think makes more sense -- indeed, the format without the
inferior list is what we display for a pending breakpoint that has
never had any locations assigned, so I think this change in behaviour
makes GDB more consistent.
Alan Modra [Sat, 20 Jul 2024 02:53:59 +0000 (12:23 +0930)]
Re: binutils: Add a test for strip with build notes
The new test wasn't being run, and failed due to relocations against
.gnu.build.attributes being stripped by default strip behaviour.
We probably should be keeping these relocations, but I haven't made
that change here.
BTW, the new test fails on ia64-hpux but that's just a repeat of the
existing note-5 fail.
PR 31999
* testsuite/binutils-all/strip-16.d: strip with --strip-unneeded
and --merge-notes.
* testsuite/binutils-all/objcopy.exp: Run the new test. Sort
other strip tests.
MIPS/opcodes: Mark MT thread context move assembly idioms as aliases
A number of instructions in the regular MIPS opcode table are assembly
idioms for the MT thread context move MFTR and MTTR instructions, so
mark them as aliases accordingly. Add suitable test cases, which also
cover the PAUSE assembly idiom.
PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in
the regular MIPS opcode table, matching the microMIPS opcode table. A
test case will be supplied separately.
A number of coprocessor move encodings have been randomly sprinkled over
the regular MIPS and microMIPS opcode tables rather than where they'd be
expected following the alphabetic order. Fix the ordering, taking into
account precedence where it has to be observed for correct disassembly.
No functional change.
Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS
opcode tables, just as with the MIPS16 opcode table, and use it
throughout. No functional change.
YunQiang Su [Fri, 19 Jul 2024 18:01:52 +0000 (19:01 +0100)]
MIPS/opcodes: Remove the regular MIPS "+t" operand code
The semantics of the regular MIPS "+t" operand code is exactly the same
as that of the "E" operand code, so replace the former with the latter
in the single MFTC0 instruction with implicit 'sel' == 0 encoding where
it's used, matching the encoding with explicit 'sel' as well as other
instructions.
MIPS/opcodes: Output thread context registers numerically with MFTR/MTTR
We print MFTR and MTTR instructions' thread context register operand in
disassembly using the ABI name the register number would correspond to
should the targeted register be a general-purpose register.
However in most cases it is wrong, because general-purpose registers are
only referred when the 'u' and 'sel' operands are 1 and 0 respectively.
And even in these cases the MFGPR and MTGPR aliases take precedence over
the corresponding generic instruction encodings, so you won't see the
valid case to normally trigger.
Conversely decoding the thread context register operand numerically is
always valid, so switch to using it. Adjust test coverage accordingly.
MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros
As from commit ab90248154ba ("Add structures to describe MIPS
operands"), <https://sourceware.org/ml/binutils/2013-07/msg00135.html>,
the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros
has been removed.
Similarly as from commit c3c0747817f4 ("Use operand structures for
MIPS16"), <https://sourceware.org/ml/binutils/2013-07/msg00136.html>,
the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed.
And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"),
<https://sourceware.org/ml/binutils/2013-07/msg00139.html>, none of the
OP_OP macros are used anymore.
Discard all the unused macros then and only keep the small subset that
is still referred. This simplifies maintenance and removes the need to
keep the artificial arrangement where some regular MIPS and microMIPS
macros expand to 0 and are kept for compatibility with the opposite ISA
mode only, as it used to be required before the commit referred.
MIPS/opcodes: Correct documentation for R6 operand types
The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which
is the target register rather than the source register. Additionally
the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand
of the BOVC/BNVC and the BEQC/BNEC instructions respectively. Also the
"-x" operand type does not permit 'rs' to be the same as 'rt'.
Correct inline documentation in opcode/mips.h accordingly.
MIPS/opcodes: Exclude $0 from "-x" R6 operand type
The "-x" operand type is used for the reverse encoding of the BOVC and
BNVC instructions, where 'rs' and 'rt' have been supplied as the second
and the first operand respectively rather than the order the instruction
expects.
In this case we require the register associated with the "-x" operand to
have a higher number than the register associated with the preceding "t"
operand, which precludes the use of $0. The case where 'rs' and 'rt'
both refer to the same register is handled by the straight encoding of
the BOVC and BNVC instructions, which come in the opcode table ahead of
the corresponding reverse encoding.
Therefore clear the ZERO_OK flag for the "-x" operand. No need for an
extra test case as the encodings involved are already covered by "r6"
and its associated GAS tests.
Jan Beulich [Fri, 19 Jul 2024 09:58:58 +0000 (11:58 +0200)]
Sparc: relax gas testsuite whitespace expectations
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
Jan Beulich [Fri, 19 Jul 2024 09:58:26 +0000 (11:58 +0200)]
TilePro: correct macro use in gas testsuite
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate (and far less intrusive) here.
Jan Beulich [Fri, 19 Jul 2024 09:58:04 +0000 (11:58 +0200)]
MIPS: correct macro use in gas and ld testsuites
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
former appears more appropriate here, as the macro parameters already
have ":req".
Jan Beulich [Fri, 19 Jul 2024 09:57:12 +0000 (11:57 +0200)]
ia64: correct macro use in gas testsuite
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate here.
Jan Beulich [Fri, 19 Jul 2024 09:56:46 +0000 (11:56 +0200)]
bfin: drop _ASSIGN_BANG
A few testcases demonstrate that "=!" isn't supposed to be an
individual token, since "= !" is used in a number of places. So far
lexing that to a single token worked because of the scrubber being
overly aggressive in removing whitespace. As that's going to change,
replace uses by separate ASSIGN and BANG.
Jan Beulich [Fri, 19 Jul 2024 09:56:20 +0000 (11:56 +0200)]
bfin: correct macro use in gas testsuite
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter really isn't an option here.
Jan Beulich [Fri, 19 Jul 2024 09:55:54 +0000 (11:55 +0200)]
Arm: correct macro use in gas testsuite
The way the inner macro invocations are written doesn't quite work as
expected (and would actually break subsequently): Due to overly
aggressive removal of whitespace by the scrubber, the incoming \sym and
\offset arguments actually get concatenated; an empty 3rd argument is
being passed to ldrtest2. That just so happened to work as intended; any
use of \offset alone would have exposed the problem. Quote the 3rd
argument, thus retaining enough whitespace to be independent of scrubber
internals.
Jan Beulich [Fri, 19 Jul 2024 09:54:45 +0000 (11:54 +0200)]
gas: adjust impossible/bogus M68K/MRI special case when scrubbing
State 1 is uniformly handled further up. And it is highly questionable
that in state 10 (i.e. after having seen not only a possible label, but
also an opcode), which is about to go away anyway, a line comment char
could still be meant to take effect. With the state checking dropped,
the immediately preceding logic can then also be simplified.
Jan Beulich [Fri, 19 Jul 2024 09:54:09 +0000 (11:54 +0200)]
gas: consistently drop trailing whitespace when scrubbing
From especially the checks for the two separator forms it appears to
follow that the construct being touched is about trailing whitespace. In
such a case, considering that for many targets ordinary and line comment
chars overlap, take into account that line comment chars override
ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually
depends on that ordering, and also accounts for this overriding).
Plus of course IS_NEWLINE() would better also be consulted. Note also
that the DOUBLESLASH_LINE_COMMENTS change should generally have no
effect just yet; it's a prereq for a later change but better fits here.
Leave respective comments as well, and update documentation to correct
which comment form is actually replaced by a single blank (i.e. neither
the ones starting with what {,tc_}comment_chars[] has nor the ones
starting with what line_comment_chars[] has).
projects / thirdparty / binutils-gdb.git / log
