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.
Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
versions beginning with the version 20190608-Base-Ratified removed this
restriction. Because the 'E' extension is still a draft, the author chose
to *just* remove the conflict (not checking the ISA version).
Note that, because RV32E is only used with a soft-float calling convention,
there's no valid official ABI for RV32EF. It means, even if we can assemble
a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
in an unmanaged state (outside ABI management).
The purpose of this commit is to suppress unnecessary errors while parsing
an ISA string and/or disassembling, not to allow hard-float with RVE.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
because only older specifications disallowed it.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
prohibited.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.
MI version 1 is long since obsolete. Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.
This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
