This adds a 'rust_at_least' helper proc, for checking the version of
the Rust compiler in use. It then changes various tests to use this
with 'require'.
With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
...
compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
gnatmake: "prog.adb" compilation error
FAIL: gdb.ada/verylong.exp: compilation prog.adb
...
AFAICT, support for Long_Long_Long_Integer was added in gcc 11.
Fix this by requiring gnatmake version 11 or higher in the test-case.
Tested on x86_64-linux.
The ERROR_NO_INFERIOR macro is already called at the beginning of the
function continue_command. Since target/inferior are not switched in-between,
the second call to it is redundant.
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
It was pointed out during review of another patch that the function
displaced_step_dump_bytes really isn't specific to displaced stepping,
and should really get a more generic name and move into gdbsupport/.
This commit does just that. The function is renamed to
bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The
function implementation doesn't really change. Much...
... I have updated the function to take an array view, which makes it
slightly easier to call in a couple of places where we already have a
gdb::bytes_vector. I've then added an inline wrapper to convert a raw
pointer and length into an array view, which is used in places where
we don't easily have a gdb::bytes_vector (or similar).
Updated all users of displaced_step_dump_bytes.
There should be no user visible changes after this commit.
Finally, I ended up having to add an include of gdb_assert.h into
array-view.h. When I include array-view.h into common-utils.h I ran
into build problems because array-view.h calls gdb_assert.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While investigating a displaced stepping issue I wanted an easy way to
see what GDB thought the original instruction was, and what
instruction GDB replaced that with when performing the displaced step.
We do print out the address that is being stepped, so I can track down
the original instruction, I just need to go find the information
myself.
And we do print out the bytes of the new instruction, so I can figure
out what the replacement instruction was, but it's not really easy.
Also, the code that prints the bytes of the replacement instruction
only prints 4 bytes, which clearly isn't always going to be correct.
In this commit I remove the existing code that prints the bytes of the
replacement instruction, and add two new blocks of code to
displaced_step_prepare_throw. This new code prints the original
instruction, and the replacement instruction. In each case we print
both the bytes that make up the instruction and the completely
disassembled instruction.
Here's an example of what the output looks like on x86-64 (this is
with 'set debug displaced on'). The two interesting lines contain the
strings 'original insn' and 'replacement insn':
(gdb) step
[displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now
[displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 <puts@got.plt>
[displaced] prepare: selected buffer at 0x401052
[displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] fixup_riprel: %rip-relative addressing used.
[displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036
[displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff
[displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052
[displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx)
[displaced] finish: restored 2892655.2892655.0 0x401052
[displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ...
[displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578
0x00007ffff7e402c0 in puts () from /lib64/libc.so.6
(gdb)
One final note. For many targets that support displaced stepping (in
fact all targets except ARM) the replacement instruction is always a
single instruction. But on ARM the replacement could actually be a
series of instructions.
The debug code tries to handle this by disassembling the entire
displaced stepping buffer. Obviously this might actually print more
than is necessary, but there's (currently) no easy way to know how
many instructions to disassemble; that knowledge is all locked in the
architecture specific code. Still I don't think it really hurts, if
someone is looking at this debug then hopefully they known what to
expect.
Obviously we can imagine schemes where the architecture specific
displaced stepping code could communicate back how many bytes its
replacement sequence was, and then our debug print code could use this
to limit the disassembly. But this seems like a lot of effort just to
save printing a few additional instructions in some debug output.
I'm not proposing to do anything about this issue for now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Fix test-case gdb.guile/scm-parameter.exp for remote host by taking into
account that gdb_reinitialize_dir has no effect for remote host.
Tested on x86_64-linux.
This function doesn't just initialise for compression, it actually
compresses. This patch sanity checks section size before allocating
buffers for the uncompressed contents.
* compress.c (bfd_init_section_compress_status): Sanity check
section size.
We have way too much duplicated code in bfd. Apply dd3a3d0af9 and
920581c57e to pdp11.c.
* pdp11.c (bfd_free_cached_info): Free line_buf. Return true
if tdata.aout_data is NULL.
run_host_cmd adds $gcc_B_opt and $ld_L_opt to the command line if it
detects the program being run is a compiler. Since the program being
run in lto.exp linking pr28138 is "sh", we need to add these by hand.
This isn't exactly as run_host_cmd does, as it lacks reordering of
any user -B option in $CC_FOR_TARGET, but it's better than ignoring
gcc_B_opt. This fixes a mips64 testsuite fail.
ld_compile adds CFLAGS_FOR_TARGET and other flags as well, so there
is no need for the ld_compile command line to include
CFLAGS_FOR_TARGET. Fixing this is just a tidy.
* testsuite/ld-plugin/lto.exp: Add gcc_B_opt, CFLAGS_FOR_TARGET
and $ld_L_opt to pr28138 link line.
* testsuite/lib/ld-lib.exp (run_ld_link_tests): Don't pass
unnecessary flags to ld_compile.
(run_ld_link_exec_tests, run_cc_link_tests): Likewise.
This changes partial symbol tables to use unrelocated_addr for the
text_high and text_low members. This revealed some latent bugs in
ctfread.c, which are fixed here.
PR mi/11335 points out that an MI varobj will not display the result
of a pretty-printer's "to_string" method. Instead, it always shows
"{...}".
This does not seem very useful, and there have been multiple
complaints about it over the years. This patch changes varobj to emit
this string when possible, and updates the test suite.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
When an allow_* proc returns false, it can be a bit difficult what check
failed exactly, if the procedure does multiple checks. To make
investigation easier, I propose to allow the "require" callbacks to be
able to return a list of two elements: the zero/non-zero value, and a
reason string.
Use the new feature in allow_hipcc_tests to demonstrate it (it's also
where I hit actually hit this inconvenience). On my computer (where GDB
is built with amd-dbgapi support but where I don't have a suitable GPU
target), I get:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests (no suitable amdgpu targets found)
vs before:
UNSUPPORTED: gdb.rocm/simple.exp: require failed: allow_hipcc_tests
Change-Id: Id1966535b87acfcbe9eac99f49dc1196398c6578
Approved-By: Tom de Vries <tdevries@suse.de>
Fix test-case gdb.server/sysroot.exp for remote host, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host/target, unless
remote host == remote target.
Tested on x86_64-linux.
Require non-remote host for test-case gdb.server/multi-ui-errors.exp, because
it uses "spawn -pty", which creates a pty on build, which gdb cannot use on
remote host.
Tested on x86_64-linux.
When running test-case gdb.server/stop-reply-no-thread-multi.exp with
host+target board local-remote-host-native, I run into a time-out:
...
(gdb) PASS: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
to_disable=: disconnect
builtin_spawn /usr/bin/ssh -t -l vries 127.0.0.1 gdbserver --once \
localhost:2346 stop-reply-no-thread-multi^M
Process stop-reply-no-thread-multi created; pid = 32600^M
Listening on port 2346^M
set remote threads-packet off^M
FAIL: gdb.server/stop-reply-no-thread-multi.exp: target-non-stop=off: \
to_disable=: set remote threads-packet off (timeout)
...
This is due to this line in ${board}_spawn:
...
set board_info($board,fileid) $spawn_id
...
We have the following series of events:
- gdb is spawned, setting fileid
- a few gdb commands (set height etc) are send using fileid, arrive at gdb and
are successful
- gdbserver is spawned, overwriting fileid
- the next gdb command is sent using fileid, so it's send
to gdbserver instead of gdb, and we run into the timeout.
There is some notion of current gdb, tracked in both gdb_spawn_id and fileid
of the host board (see switch_gdb_spawn_id). And because the host and target
board are the same, spawning something on the target overwrites the fileid on
host, and consequently the current gdb.
Fix this by only setting fileid when spawning gdb.
Tested on x86_64-linux.
Now gdb.server/*.exp passes for host+target board local-remote-host-native,
except for file-transfer.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29734
When running update-freebsd.sh on FreeBSD, I see the following
modification in freebsd.xml,
-<!-- Copyright (C) 2009-2023 Free Software Foundation, Inc.
+<!-- Copyright (C) 2009-2020 Free Software Foundation, Inc.
It means that each time, when we running the update-freebsd.sh on
FreeBSD, we have to correct the year of copyright manually. So fix this
issue by using dynamic year.
Tested by regenerating freebsd.xml on FreeBSD/amd64.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
With test-case gdb.server/non-existing-program.exp and native, I have reliably:
...
(gdb) builtin_spawn gdbserver stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
But with target board remote-gdbserver-on-localhost I sometimes have:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l remote-target localhost gdbserver \
stdio non-existing-program^M
stdin/stdout redirected^M
/bin/bash: line 0: exec: non-existing-program: not found^M
During startup program exited with code 127.^M
Exiting^M
Connection to localhost closed.^M^M
PASS: gdb.server/non-existing-program.exp: gdbserver exits cleanly
...
and sometimes the exact same output, but a FAIL instead.
Fix this by replacing "Exiting\r\n$" with "Exiting\r\n" in the regexps.
Tested on x86_64-linux.
Given p = A where p is a pointer to some type and A is an array of
that type, then the expression p - 1 + 1 evokes undefined behaviour
according to the C standard.
gcc-13 -fsanitize=address,undefined complains about this, but not
where the undefined behaviour actually occurs at tc-m68hc11.c:646.
Instead you get an error: "tc-m68hc11.c:708:20: runtime error: store
to address 0x62600000016c with insufficient space for an object of
type 'int'". Which is a lie. There most definitely is space there.
Oh well, diagnostics are sometimes hard to get right. The UB is easy
to avoid.
PR 30279
* config/tc-m68hc11.c (md_begin): Avoid undefined pointer
decrement. Remove unnecessary cast.
Proc allow_rust_tests returns 0 when there's no rust compiler, but that gives
the wrong answer for gdb.rust/expr.exp, which doesn't require it.
Fix this by using can_compile rust in the test-cases that need it, and just
returning 1 in allow_rust_tests.
Tested on x86_64-linux.
If I deinstall the rust compiler, I get:
...
gdb compile failed, default_target_compile: Can't find rustc --color never.
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
Fix this by adding can_compile rust, and using it in allow_rust_tests, such
that we have instead:
...
UNSUPPORTED: gdb.rust/watch.exp: require failed: allow_rust_tests
...
Since the rest of the code in allow_rust_tests is also about availability of
the rust compiler, move it to can_compile.
Tested on x86_64-linux.
With test-case gdb.rust/watch.exp and remote host I run into:
...
Executing on host: gcc watch.rs -g -lm -o watch (timeout = 300)
...
ld:watch.rs: file format not recognized; treating as linker script
ld:watch.rs:1: syntax error
...
UNTESTED: gdb.rust/watch.exp: failed to prepare
...
The problem is that find_rustc returns "" for remote host, so we fall back to gcc, which fails.
Fix this by returning 0 in allow_rust_tests for remote host.
Tested on x86_64-linux.
Fix gnat_runtime_has_debug_info for remote host by checking for
allow_ada_tests.
This fixes an error for test-case gdb.testsuite/gdb-caching-proc.exp and
remote host.
Tested on x86_64-linux.
Use GDB_SIGNAL_TRAP instead of SIGTRAP. This is a no-op since the
value of SIGTRAP on FreeBSD matches the value of GDB_SIGNAL_TRAP, but
it is more correct.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This is in #ifdef'd code for a workaround for FreeBSD versions older
than 11.1 which is why it wasn't caught earlier.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The real problem is that libcollector doesn't interpose thread_create@GLIBC_2.34
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example, dlopen@GLIBC_2.34,
dlopen@GLIBC_2.17, dlopen@GLIBC_2.2.5, etc.
We have to interpose each of the functions because we don't know
which version of libC will be used during profiling.
Historically, we have used three versions of scripts (mapfile.aarch64-Linux,
mapfile.amd64-Linux, mapfile.intel-Linux).
Three are not needed. One is enough
The fixes below include:
- merged all version symbols into one version script.
- added new version symbols which are defined in latest versions of libC.
- removed unused defines and duplicated code.
- added the DCL_FUNC_VER macro to define the version symbols.
Tested on x86_64 and aarch64 (OL8/OL9). No regression.
gprofng/ChangeLog
2023-03-23 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30089
* libcollector/Makefile.am: Use libgprofng.ver instead of mapfile.*
* libcollector/configure.ac: Delete GPROFNG_VARIANT.
* src/collector_module.h: Move the SYMVER_ATTRIBUTE macro to collector.h
* libcollector/collector.h: Add macros (SYMVER_ATTRIBUTE, DCL_FUNC_VER).
Remove unused defines.
* libcollector/dispatcher.c: Interpose functions from libC.
Clean up the old code.
* libcollector/iotrace.c: Likewise.
* libcollector/libcol_util.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/libgprofng.ver: New file.
* libcollector/Makefile.in: Rebuild.
* libcollector/configure: Rebuild.
* libcollector/mapfile.aarch64-Linux: Removed.
* libcollector/mapfile.amd64-Linux: Removed.
* libcollector/mapfile.intel-Linux: Removed.
* libcollector/mapfile.sparc-Linux: Removed.
* libcollector/mapfile.sparcv9-Linux: Removed.
I noticed that some debug log output printing an lwp's pending status
wasn't considering lp->waitstatus. This fixes it, by introducing a
new pending_status_str function.
Also fix the comment in gdb/linux-nat.h describing
lwp_info::waitstatus and details the description of lwp_info::status
while at it.
Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980
Approved-By: Andrew Burgess <aburgess@redhat.com>
This commit tweaks displaced_step_finish & friends to pass down a
target_waitstatus instead of a gdb_signal. This is needed because a
patch later in the step-over-{thread-exit,clone] series will want to
make displaced_step_buffers::finish handle
TARGET_WAITKIND_THREAD_EXITED. It also helps with the
TARGET_WAITKIND_THREAD_CLONED patch later in that same series.
It's also a bit more logical this way, as we don't have to pass down
signals when the thread didn't actually stop for a signal. So we can
also think of it as a clean up.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27338
Change-Id: I4c5d338647b028071bc498c4e47063795a2db4c0
Approved-By: Andrew Burgess <aburgess@redhat.com>
