This patch is a few minor cleanups to rust-lang.c: renaming a
badly-named local variable, moving a couple of declarations into 'for'
headers, and using 'bool' in one spot.
PR/32363.
Gas was incorrectly translating
stm sp!, {regs}
into
push {regs}
but this is invalid. Conversely, it was also failing to translate
stmfd sp!, {lowregs[, lr]}
into a 16-bit push instruction. Fortunately stmia SP! is unlikely to be
a common idiom on a full-descending stack as it writes values to the stack,
then immediately deallocates that bit of the stack.
Fixed this and cleaned up the logic somewhat. While there, change some of
the ordering so that "ldm base, {base}" is transformed preferentially to
LDR. This is in keeping with the general preference in the Arm ARM for
avoiding single register LDM instructions.
Consider operate-and-get-next [1] in bash:
...
$ <echo 1>echo 1<enter>
1
$ <echo 2>echo 2<enter>
2
$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
1
$ echo 2<Ctrl-o>
2
$ echo 1
...
So, typing Ctrl-o:
- executes the recalled command, and
- prefills the next one (which then can be executed again with Ctrl-o).
We have the same functionality in gdb, but when recalling the last command
from history with bash we have no prefill:
...
$ <echo 1>echo 1<enter>
1
$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
1
$
...
but with gdb do we have a prefill:
...
(gdb) echo 1\n
1
(gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o>
1
(gdb) echo 1\n
...
Following the principle of least surprise [2], I think gdb should do what bash
does.
Fix this by:
- signalling this case in gdb_rl_operate_and_get_next using
"operate_saved_history = -1", and
- handling operate_saved_history == -1 in
gdb_rl_operate_and_get_next_completion.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/32485
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485
[1] https://www.man7.org/linux/man-pages/man3/readline.3.html
[2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
This changes one spot in ada-lang.c to use block::is_static_block
rather than a hand-rolled implementation. Note this also fixes the
call -- what is currently written there is wrong.
Approved-By: Tom de Vries <tdevries@suse.de>
gdbpy_lookup_static_symbols is missing an error check for the case
where symbol_to_symbol_object returns NULL.
Approved-By: Tom de Vries <tdevries@suse.de>
On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run
into:
...
(gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr"
Quit^M
...
The test-case already contains a related workaround:
...
# Get rid of symbols from shared libraries, otherwise
# "b -source thr<tab>" could find some system library's
# source.
gdb_test_no_output "nosharedlibrary"
...
but that doesn't work in this case because the debug info is in the executable
itself:
...
The File Name Table (offset 0xb5):
Entry Dir Time Size Name
1 0 0 0 abi-note.c
2 1 0 0 types.h
3 2 0 0 stdint-intn.h
4 2 0 0 stdint-uintn.h
5 3 0 0 elf.h
6 4 0 0 thread_pointer.h
...
due to debug info in some glibc object file.
Fix this by:
- using -nostdlib, ensuring only debug info from the three test-case sources
is present in the executable, and
- adding a _start wrapping main.
Tested on x86_64-linux and ppc64le-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR testsuite/31229
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229
Also add the post DWARF5 language codes to gold/gdb-index.cc
Gdb_index_info_reader::visit_top_die check as --gdb-index only
supports C and C++ languages and emits warning otherwise.
Introduce an RSP packet, 'x', for reading from the remote server
memory in binary format. The binary write packet, 'X' already exists.
The 'x' packet is essentially the same as 'm', except that the
returned data is in binary format. For transferring relatively large
data from the memory of the remote process, the 'x' packet can reduce the
transfer costs.
For example, without this patch, fetching ~100MB of data from a remote
target takes
(gdb) dump binary memory temp.o 0x00007f3ba4c576c0 0x00007f3bab709400
2024-03-13 16:17:42.626 - command started
2024-03-13 16:18:24.151 - command finished
Command execution time: 32.136785 (cpu), 41.525515 (wall)
(gdb)
whereas with this patch, we obtain
(gdb) dump binary memory temp.o 0x00007fec39fce6c0 0x00007fec40a80400
2024-03-13 16:20:48.609 - command started
2024-03-13 16:21:16.873 - command finished
Command execution time: 20.447970 (cpu), 28.264202 (wall)
(gdb)
We see improvements not only when reading bulk data as above, but also
when making a large number of small memory access requests.
For example, without this patch:
(gdb) pipe x/100000xw $pc | wc -l
2024-03-13 16:04:57.112 - command started
25000
2024-03-13 16:05:10.798 - command finished
Command execution time: 9.952364 (cpu), 13.686581 (wall)
With this patch:
(gdb) pipe x/100000xw $pc | wc -l
2024-03-13 16:06:48.160 - command started
25000
2024-03-13 16:06:57.750 - command finished
Command execution time: 6.541425 (cpu), 9.589839 (wall)
(gdb)
Another example, where we create a core file of a GDB process.
(gdb) gcore /tmp/core.1
...
Command execution time: 85.496967 (cpu), 133.224373 (wall)
vs.
(gdb) gcore /tmp/core.1
...
Command execution time: 48.328885 (cpu), 115.032289 (wall)
Regression-tested on X86-64 using the unix (default) and
native-extended-gdbserver board files.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
When started with the --debug=remote flag, gdbserver enables the debug
logs for the received and sent remote packets. If the packet contents
are too long or contain verbatim binary data, printing the contents
may create noise in the logs or even distortion in the terminal output.
Introduce a function, `suppress_next_putpkt_log`, that allows omitting
the contents of a sent package in the logs. This can be useful when a
certain packet handler knows that it is sending binary data.
My first attempt was to implement this mechanism by passing an extra
parameter to putpt_binary_1 that could be controlled by the caller,
putpkt_binary or putpkt. However, all qxfer handlers, regardless of
whether they send binary or ascii data, cause the data to be sent via
putpkt_binary. Hence, the solution was going to be either too
suppressive or too intrusive. I opted for the approach where a package
handler would suppress the log explicitly.
Approved-By: Tom Tromey <tom@tromey.com>
Revise a sentence to avoid misinterpretation. Move @cindex entries
before the text they index. Refer to trace frames regarding partial
reads.
Approved-By: Eli Zaretskii <eliz@gnu.org>
The fix for PR binutils/31872 (commit b20ab53f81) neglected the case
of targets with only RELA support, where nevertheless object files using
REL exist. In particular objcopy will create such objects for x86-64
when converting from an i?86 ELF object (this by itself probably isn't
quite right, but we ought to cope with what our own tools are doing).
Restore the fallback to the RELA lookup, just without re-introducing the
blind NULL de-ref that was there before.
readelf and objdump differ in output for 32-bit vs 64-bit.
* testsuite/gas/loongarch/dwarf-regnum.d: Adjust to suit both
32-bit and 64-bit output.
* testsuite/gas/loongarch/localpic.d: Likewise.
Both of these targets extend elf_link_hash_entry, so arguably should
set hash_table_id to something other than GENERIC_ELF_DATA. The patch
also sorts enum elf_target_id.
aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that.
These are all targets that use other than GENERIC_ELF_DATA in their
object and hash table ids.
* elf32-am33lin.c,
* elf32-csky.c,
* elf64-ia64-vms.c,
* elf64-sparc.c,
* elfnn-aarch64.c,
* elfnn-kvx.c (ELF_TARGET_ID): Define.
The current gdb-add-index manual page is a bit out-of-date. This
commit fixes a few deficiencies:
- gdb-add-index does not use objdump; it uses objcopy and readelf
- missing info on environment variables (in appropriate ENVIRONMENT section).
- missing mention of -dwarf-5 option
- adds important notice about FILENAME being writable
- explains exit status
- the script adds appropriate section(s) to the file; it does not
output new files with the section(s)
Approved-By: Eli Zaretskii <eliz@gnu.org>
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
This adds a new Python script that checks the header guards of all gdb
source files. It enforces a fairly strict formatting and naming
scheme.
In particular, for a file "x/y-z.h" (relative to the repository root),
the include guard will be named "X_Y_Z_H". Only the '#ifndef' form is
allowed, not "#if !defined(...)". The trailing comment on the
"#endif" is also required.
The script also tries to update files that appear to have the required
lines if they are in the wrong form or use the wrong name.
Reviewed-By: Tom de Vries <tdevries@suse.de>
The script in the next patch noticed some irregularities in some
headers: trailing or leading blank lines, or in one case a missing
copyright header. This patch fixes these.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Oleg pointed out that when renaming from "status" to "enabled" in the
Python TUI events patch, I neglected to update one spot in the
documentation. This patch fixes this. I'm checking it in as obvious.
You can verify that this change is correct by examining
gdb/python/py-event-types.def.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162
In this patch, we will support SM4 AVX10.2 extension part. It is
a promotion from VEX encoding to EVEX encoding. The EVEX encoding
is based on AVX10.2, which is the same as the upcoming MOVRS ISA.
Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS.
While I have also tried to merge the table like AVX/AVX512, I
choose to just templatize the table. I am okay to go either way,
but slightly prefer the templatizing one since probably SM4 would
be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS
does not need that). Also, it is a tendancy that we will directly
provide EVEX encodings and no VEX encodings for vector instructions
since AVX10. This will make the adding in gas/config/tc-i386.c not
that worthy.
gas/ChangeLog:
* NEWS: Support Intel SM4 EVEX instructions.
* config/tc-i386.c (_is_cpu): Handle AVX10.2.
* testsuite/gas/i386/i386.exp: Run SM4 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-256-sm4-intel.d: Add SM4 tests.
* testsuite/gas/i386/avx10_2-256-sm4.d: Ditto.
* testsuite/gas/i386/avx10_2-256-sm4.s: Ditto.
* testsuite/gas/i386/avx10_2-512-sm4-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-512-sm4.d: Ditto.
* testsuite/gas/i386/avx10_2-512-sm4.s: Ditto.
* testsuite/gas/i386/avx10_2-sm4-inval.l: Ditto.
* testsuite/gas/i386/avx10_2-sm4-inval.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-sm4-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-sm4.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-sm4.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-sm4-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-sm4.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-sm4.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-sm4-inval.l: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-sm4-inval.s: Ditto.
opcodes/ChangeLog:
* i386-dis-evex.h: Add evex table entry for SM4.
* i386-dis.h: Ditto.
* i386-opc.h: (i386_cpu): Move AVX10.2 to CPU_FLAGS_COMMON.
* i386-opc.tbl: Add SM4 EVEX instructions.
* i386-init.h: Regenerated.
* i386-tbl.h: Ditto.
This patch changes a few spots in rust-parse.c to use 'bool', and also
declares a couple of loop iteration variables in the loop headers.
I'm checking this in.
After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number",
no need to do special handling when generating xml file for LoongArch,
just remove the tips in the file comment.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: Tom de Vries <tdevries@suse.de>
In gdb commit a08dc2aa00 ("gdb: syscalls: Add loongarch-linux.xml.in"),
we find:
There exist some __NR3264_ prefixed syscall numbers, replace them
with digital numbers according to /usr/include/asm-generic/unistd.h
and sort them by syscall number manually, maybe we can modify the
script to do it automatically in the future.
It is time to do it now, just handle __NR3264_ prefixed syscall number
automatically in the script update-linux.sh.
By the way, a Linux kernel patch did the similar change [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6e1cc6b7220
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: Tom de Vries <tdevries@suse.de>
gas generates an information diagnostic message for every context
invoking a macro and generating a warning or error message.
For the specific case of sysreg tests, this pollutes the expected
error output for no benefit in term of test debug or testing coverage.
This patch aims at stopping such diagnostic messages to be generated
for the failure tests by providing --no-info flag to gas.
It also removed from the expected outputs the information messages
related to macro expansions.
gas currently emits informational messages for context information along warnings.
In the context of system register tests in AArch64 backend, these messages
pollute the tests when checking for error message patterns in stderr output.
This patch aims at providing two new flags while preserving the existing
behavior if none of the options is provided.
* --info, similar to the existing --warn flag to enable diagnostic
informational messages (default behavior).
* --no-info, similar to the existing --no-warn flag to disable diagnostic
informational messages.
It also adds the flags to the existing documentation, and command manual.
In regcache_raw_read_unsigned, we unconditionally return REG_VALID as
the register status. This does not seem right, since the register may
in fact be in another state, such as REG_UNAVAILABLE. Return the
tracked status.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The registers_valid field of the regcache struct is used for tracking
whether we have attempted to fetch all the registers from the target.
Its name does not reflect this well, I think. It falsely gives the
impression that all the registers are valid. This may conflict an
individual register status, which could be REG_UNAVAILABLE. To better
reflect the purpose, rename the field to "registers_fetched".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The registers_valid and registers_owned fields of the regcache struct
are of type int. Make them bool.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
A regcache can be initialized with a register value buffer, in which
case, the register_status pointer is null. This condition is checked
in set_register_status, but not in get_register_status. Do this check
for consistence and safety.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Boolify the 'fetch' parameter of the get_thread_regcache function.
All of the current uses pass true for this parameter. Therefore, define
its default value as true and remove the argument from the uses.
We still keep the parameter, though, to give downstream targets the
option to obtain a regcache without having to fetch the whole
contents. Our (Intel) downstream target is an example.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The `get_thread_regcache` function has a `fetch` option to skip
fetching the registers from the target. It seems this option is set
to false only at uses where we just need to access the tdesc through
the regcache of the current thread, as in
struct regcache *regcache = get_thread_regcache (current_thread, 0);
... regcache->tdesc ...
Since the tdesc of a regcache is set from the process of the thread
that owns the regcache, we can simplify the code to access the tdesc
via the process, as in
... current_process ()->tdesc ...
This is intended to be a refactoring with no behavioral change.
Tested only for the linux-x86-low target.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
