The test case introduced in bafcc33526 (Fix stepping in rtld without
debug symbol) fails on some systems as reported by PR/29768. This can
be seen if the system does not have debug info for the libc:
(gdb) step^M
Single stepping until exit from function main,^M
which has no line number information.^M
hello world[Inferior 1 (process 48203) exited normally]^M
(gdb) PASS: gdb.base/rtld-step-nodebugsym.exp: step
continue^M
The program is not being run.^M
(gdb) FAIL: gdb.base/rtld-step-nodebugsym.exp: continue until exit (the program is no longer running)
Without glibc debug info, GDB steps until the program finishes, and
then "gdb_continue_to_end" fails.
As this test was designed to check that GDB does not crash in the "step"
command, the continue does not carry real meaning to the test.
Replace it by "print 0" so we still check that after the step command
GDB is still alive, which is what we care about.
Tested on Ubuntu-22.04 x86_64, with and without libc6-dbg.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29768
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Nothing passes this to dgen, and even if it did, nothing would happen
because the generated spreg.[ch] files don't include any references
back to the original data table. So drop it to simplify.
Since we know we'll return 0 by default, we don't have to output case
statements for readonly or length fields whose values are also zero.
This is the most common case by far and thus generates a much smaller
switch table in the end.
Instead of writing:
case 1:
return 1;
case 2:
return 1;
...etc...
Output a single return so we get:
case 1:
case 2:
case ...
return 1;
This saves ~100 lines of code. Hopefully the compiler was already
smart enough to optimize to the same code, but if not, this probably
helps there too :).
This saves a single line for the same result. By itself, it's not
interesting, but we can further optimize the generated output and
completely omit the switch table in some cases. Which we'll do in
follow up commits.
PR tdep/28796
As reported, we are using some memory read routines that don't handle read
errors gracefully. Convert those to use the safe_* versions if available.
This allows the code to handle those read errors in a more sensible way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28796
Commit be6276e0ae "Allow debugging of runtime loader / dynamic linker"
introduced a small regression when stepping into the runtime loader /
dynamic linker from function we do not have debug information for. This
is reported in PR/29747.
This can be shown by the following example (given by Simon Marchi in
buzilla bug report):
$ cat test.c
#include <stdio.h>
int main()
{
printf("Hi\n");
return 0;
}
$ gcc test.c -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory test -ex start -ex s
Reading symbols from test...
(No debugging symbols found in test)
Temporary breakpoint 1 at 0x1151
Starting program: .../binutils-gdb/gdb/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, 0x0000555555555151 in main ()
Single stepping until exit from function main,
which has no line number information.
/home/smarchi/src/binutils-gdb/gdb/infrun.c:6960:64: runtime error: member call on null pointer of type 'struct symbol'
The crash happens here:
#0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
#1 0x00007ffff5dd7128 in __ubsan::__ubsan_handle_type_mismatch_v1_abort (Data=<optimized out>, Pointer=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:148
#2 0x000055556183e1a7 in process_event_stop_test (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6960
#3 0x0000555561838ea4 in handle_signal_stop (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6615
#4 0x000055556182f77b in handle_inferior_event (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:5866
When evaluating:
6956 if (execution_direction != EXEC_REVERSE
6957 && ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
6958 && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ())
6959 && !in_solib_dynsym_resolve_code (
6961 ecs->event_thread->control.step_start_function->value_block ()
6962 ->entry_pc ()))
we dereference, ecs->event_thread->control.step_start_function which is
nullptr.
This patch changes this condition so it evaluates to true if
ecs->event_thread->control.step_start_function is nullptr since this
matches the behaviour before be6276e0ae.
Tested on ubuntu-22.04 x86_64.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29747
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Kevin Buettner <kevinb@redhat.com>
When merging ppc configure checks into the top-level, these 2 funcs
were accidentally dropped (probably due to incorrect resolution of
conflicts). Restore them since the ppc code utilizes them both.
This controls only one thing: how to call mkdir(). The gnulib code
already has a mkdir module that provides this exact logic for us, so
punt the code entirely.
Gdbserver unconditionally reports support for btrace packets. Do not
report the support, if the underlying target does not say it supports
it. Otherwise GDB would query the server with btrace-related packets
unnecessarily.
PR exp/28359 points out that 'ptype/o' does not work when the current
language is "asm".
I tracked this down to a hard-coded list of languages in typeprint.c.
This patch replaces this list with a method on 'language_defn'
instead. If all languages are ever updated to have this feature, the
method could be removed; but in the meantime this lets each language
control what happens.
I looked at having each print_type method simply modify the flags
itself, but this doesn't work very well with the feature that disables
method-printing by default (but allows it via a flag).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Keith Seitz <keiths@redhat.com>
This macro expansion was missing a set of outer-most parenthesis which
some compilers would complain about depending on how the macro is used.
This is just standard good macro hygiene too.
We've never run these helper programs directly. The igen program
includes the relevant source files directly and runs the code that
way. So stop wasting developer CPU time linking programs that are
never run. We leave the rules in place for people who need to test
and debug the specific bits of code every now & then.
Operand swapping was mistakenly suppressed when the first two operands
were immediate ones, not taking into account overall operand count. This
way EXTRQ / INSERTQ would have been accepted also with kind-of-AT&T
operand order.
For the testcase being extended, in order to not move around "GAS
LISTING" expectations, suppress pagination.
Like commit ffbe89531c this avoids more silliness writing output
that is going to be deleted. bfd_close and bfd_close_all_done differ
in that only the former calls _bfd_write_contents.
* objcopy.c (copy_archive): Don't call bfd_close for elements
that are going to be deleted, call bfd_close_all_done instead.
Do the same for the archive itself.
Although the encoding for scalar and fp registers is identical,
we should follow common pratice and use fp register names
when referencing fp registers.
The xtheadmemidx extension consists of indirect load/store instructions
which all load to or store from fp registers.
Let's use fp register names in this case and adjust the test cases
accordingly.
gas/
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Updated since rd need to
be float register.
* testsuite/gas/riscv/x-thead-fmemidx-fail.s: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.d: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.s: Likewise.
opcodes/
* riscv-opc.c (riscv_opcodes): Updated since rd need to be float register.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
I get this test failure on my CI;
FAIL: gdb.base/info-os.exp: get process list
The particularity of this setup is that builds are done in containers
who are allocated 4 CPUs on a machine that has 40. The code in
nat/linux-osdata.c fails to properly fetch the core number for each
task.
linux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which
returns 4, so it allocates an array of 4 integers. However, the core
numbers read from /proc/pid/task/tid/stat, by function
linux_common_core_of_thread, returns a value anywhere between 0 and 39.
The core numbers above 3 are therefore ignored, many processes end up
with no core value, and the regexp in the test doesn't match (it
requires an integer as the core field).
The way this the CPUs are exposed to the container is that the container
sees 40 CPUs "present" and "possible", but only 4 arbitrary CPUs
actually online:
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present
0-39
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online
5,11,24,31
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible
0-39
The solution proposed in this patch is to find out the number of
possible CPUs using /sys/devices/system/cpu/possible. In practice, this
will probably always contain `0-N`, where N is the number of CPUs, minus
one. But the documentation [1] doesn't such guarantee, so I'll assume
that it can contain a more complex range list such as `2,4-31,32-63`,
like the other files in that directory can have. The solution is to
iterate over these numbers to find the highest possible CPU id, and
use that that value plus one as the size of the array to allocate.
[1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst
Change-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3
I would like to add more code to nat/linux-osdata.c that reads an entire
file from /proc or /sys and processes it as a string afterwards. I
would like to avoid duplicating the somewhat error-prone code that reads
an entire file to a buffer. I think we should have a utility function
that does that.
Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make
linux_common_core_of_thread use it. I want to make the new function
return an std::string, and because strtok doesn't play well with
std::string (it requires a `char *`, std::string::c_str returns a `const
char *`), change linux_common_core_of_thread to use std::string methods
instead.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a
Consider a hello world a.out, started using gdbserver:
...
$ gdbserver --once 127.0.0.1:2345 ./a.out
Process ./a.out created; pid = 15743
Listening on port 2345
...
that we can connect to using gdb:
...
$ gdb -ex "target remote 127.0.0.1:2345"
Remote debugging using 127.0.0.1:2345
Reading /home/vries/a.out from remote target...
...
0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb)
...
After that, we can for instance quit with confirmation:
...
(gdb) quit
A debugging session is active.
Inferior 1 [process 16691] will be killed.
Quit anyway? (y or n) y
$
...
Or, kill with confirmation and quit:
...
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 16829) killed]
(gdb) quit
$
...
Or, monitor exit, kill with confirmation, and quit:
...
(gdb) monitor exit
(gdb) kill
Kill the program being debugged? (y or n) y
Remote connection closed
(gdb) quit
$
...
But when doing monitor exit followed by quit with confirmation, we get the gdb
prompt back, requiring us to do quit once more:
...
(gdb) monitor exit
(gdb) quit
A debugging session is active.
Inferior 1 [process 16944] will be killed.
Quit anyway? (y or n) y
Remote connection closed
(gdb) quit
$
...
So, the first quit didn't quit. This happens as follows:
- quit_command calls query_if_trace_running
- a TARGET_CLOSE_ERROR is thrown
- it's caught in remote_target::get_trace_status, but then
rethrown because it's TARGET_CLOSE_ERROR
- catch_command_errors catches the error, at which point the quit command
has been aborted.
The TARGET_CLOSE_ERROR is defined as:
...
/* Target throwing an error has been closed. Current command should be
aborted as the inferior state is no longer valid. */
TARGET_CLOSE_ERROR,
...
so in a way this is expected behaviour. But aborting quit because the inferior
state (which we've already confirmed we're not interested in) is no longer
valid, and having to type quit again seems pointless.
Furthermore, the purpose of not catching errors thrown by
query_if_trace_running as per commit 2f9d54cfce ("make -gdb-exit call
disconnect_tracing too, and don't lose history if the target errors on
"quit""), was to make sure that error (_("Not confirmed.") had effect.
Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception
during query_if_trace_running and reporting it:
...
(gdb) monitor exit
(gdb) quit
A debugging session is active.
Inferior 1 [process 19219] will be killed.
Quit anyway? (y or n) y
Remote connection closed
$
...
Tested on x86_64-linux.
PR server/15746
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746
Approved-By: Tom Tromey <tom@tromey.com>
Remove test-cases from test-names, such that we don't have the redundant:
...
PASS: gdb.base/corefile.exp: backtrace in corefile.exp
...
but simply:
...
PASS: gdb.base/corefile.exp: backtrace
...
Fixed all instances found using:
...
$ grep ":.*:.*\.exp" gdb.sum
...
Tested on x86_64-linux.
With test-case gdb.base/bigcore.exp I run into:
...
(gdb) PASS: gdb.base/bigcore.exp: get inferior pid
signal SIGABRT^M
Continuing with signal SIGABRT.^M
^M
Program terminated with signal SIGABRT, Aborted.^M
The program no longer exists.^M
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
...
due to find_core_file returning "".
There is a core file name core:
...
$ ls ./outputs/gdb.base/bigcore
bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1
...
but it's not found.
The problem is this statement:
...
lappend files [list ${::testfile}.core core]
...
which adds a single list item "${::testfile}.core core".
Fix this in the most readable way:
...
lappend files ${::testfile}.core
lappend files core
...
Tested on x86_64-linux.
The intention of this code seems to be to indicate that this insn
should not be used and produces undefined behavior, so instead of
setting registers to bogus values, call Unpredictable. This fixes
build warnings due to 32-bit/64-bit type conversions, and outputs
a log message for users at runtime instead of silent corruption.
Bug: https://sourceware.org/PR29276
This hasn't been used by gdb in decades, and doesn't make sense with
a standalone sim program/library where the ABI is fixed. So punt it
to simplify the code.
Hi all,
This wrong comment was introduced by previous AVX-VNNI-INT8 commit.
Committed as obvious fix.
BRs,
Haochen
opcodes/ChangeLog:
* i386-dis.c (VEX_W_0F3851): Corrected from
VEX_W_0F3851_P_0.
The switch to linking with libtool now shows a very long link line
even when V=0. This patch arranges to silence libtool in this
situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 64. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32-vs-64
based on the $target. We can easily merge this with the top-level
configure script to clean things up a bit.
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script.
NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
libctf.so are used by gdb if binutils is installed with
--enable-shared.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. No regressions found.
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I see failures in this test, due to the function name "add" being too
generic, and unexpected breakpoint locations being found in my
libstdc++, such as (wrapped for readability):
{
number="2.4",enabled="y",addr="0x00007ffff7d67e68",
func="(anonymous namespace)::fast_float::bigint::add",
file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
line="1815", thread-groups=["i1"]
}
Change the test to use a more unique name.
Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d
linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options. However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:
"Flags are inherited by new tracees created and "auto-attached" via
active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
options."
This removes the unnecessary call.
[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
The install code was using $SUBDIRS to track all enabled arches. This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level. Create a new var
explicitly to track the list of enabled arches instead.
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
Call the helper function "check_shared_lib_support" to ensure -shared
is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
This allows to catch custom targets explicitly disabling it.
ld/ChangeLog:
* testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
