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.
There are some new syscalls in the latest upstream Linux kernel [1],
some archs updated the xml files in the recent commit 19f3450f74
("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also
update ARM64 to reflect the reality.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-By: Tom de Vries <tdevries@suse.de>
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>
A user noticed that the sim assigns the result of a call to 'signal'
to a variable like:
RETSIGTYPE (*prev_sigint) ();
However, it's more correct to use (int) here.
This patch fixes the error.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32466
Approved-By: Andrew Burgess <aburgess@redhat.com>
This imports readline 8.2 patch 13.
This time around I thought I would try to document the process.
First I have a checkout of the upstream readline repository. I make a
local branch there, based on the previous upstream import. In this
case that was readline 8.1; see gdb commit b4f26d541a.
Then, I apply all readline changes from the gdb repository since the
previous readline import. In this case that is up to commit
3dee0baea2 in the gdb repo.
After this, I "git merge" from the relevant upstream commit. In the
past I feel like I used a tag, but readline is managed very strangely
and I didn't see a tag. So I just used the patch 13 commit, aka
commit 037d85f1 upstream.
Then I fixed all the merge conflicts. Re-running autoconf requires a
symlink from '../../config' into the gdb tree, due to the local
m4_include addition. It's possible other hacks like this are
required, I don't remember how I set things up in the past.
After this, I did a build + test of gdb. I also did a mingw
cross-hosted build, because that's caused build failures in past
imports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265
Reviewed-by: Sam James <sam@gentoo.org>
While debugging another issue, I noticed that 'rbreak' on a large
program was very slow. In particular, with 'maint time 1':
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 1940.646332 (cpu), 1960.771517 (wall)
"ps" also reported that, after this command, gdb's VSZ was 4619360.
Looking into this, I found something strange. When 'rbreak' found a
function "f" in file "file.adb", it would try to set the breakpoint
using "break 'file.adb':'f'".
This then interacted somewhat poorly with linespec. linespec first
expands all the symtabs matching "file.adb", but in this program this
results in thousands of CU expansions (probably due to inlining, but I
did not investigate).
There is probably a linespec bug here. It would make more sense for
it to combine the file- and symbol- lookups, as this is more
efficient. I plan to file a bug about this at least.
I tracked this "file:function" style of linespec to the earliest days
of gdb. Back then, "break function" would only break on the first
"function" that was found -- it wasn't until much later that we
changed gdb to break on all matching functions. So, I think that
rbreak was written this way to try to work around this limitation, and
it seems to me that this change obsoleted the need for rbreak to
mention the file at all.
That is, "break file:function" is redundant now, because plain
"break function" will redo that same work -- just more efficiently.
(The only exception to this is the case where a file is given
to rbreak -- here the extra filtering is still needed.)
This patch implements this. On the aforementioned large program, with
this patch, rbreak still sets all the desired breakpoints (879 of
them) but is now much faster:
(gdb) with pagination off -- rbreak ^command_display
[...]
Command execution time: 91.702648 (cpu), 92.770430 (wall)
It also reduces the VSZ number to 2539216.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340
Approved-By: Pedro Alves <pedro@palves.net>
'rbreak' searches symbols and then sets a number of breakpoints. If
setting one of the breakpoints fails, then 'rbreak' will terminate
before examining the remaining symbols.
However, it seems to me that it is better for 'rbreak' to keep going
in this situation. That is what this patch implements.
This problem can be seen by writing an Ada program that uses "pragma
import" to reference a symbol that does not have debug info. In this
case, the program will link but setting a breakpoint on the imported
name will not work.
I don't think it's possible to write a reliable test for this, as it
depends on the order in which symtabs are examined.
New in v2: rbreak now shows how many breakpoints it made and also how
many errors it encountered.
Regression tested on x86-64 Fedora 40.
Approved-By: Andrew Burgess <aburgess@redhat.com>
After posting this series:
https://inbox.sourceware.org/gdb-patches/cover.1733742925.git.aburgess@redhat.com
I got a failure report from the Linaro CI system. I eventually
tracked the issue down to a filename clash with glibc. I was able to
reproduce the issue when I installed the glibc debug information on to
my local machine, and ran the gdb.base/dlmopen.exp test as updated in
the above series.
Here's what's happening:
There is a file called dlmopen.c within glibc, within the glibc source
tree the file can be found at ./dlfcn/dlmopen.c. When this file is
compiled it appears that the glibc build system first enters the dlfcn
directory, and then compiles the file using the relative path
./dlmopen.c, here's a snippet of the DWARF:
<0><d5d27>: Abbrev Number: 12 (DW_TAG_compile_unit)
<d5d28> DW_AT_producer : (alt indirect string, offset: 0x16433) t
<d5d2c> DW_AT_language : 29 (C11)
<d5d2d> DW_AT_name : (indirect line string, offset: 0x5c8f): dlmopen.c
<d5d31> DW_AT_comp_dir : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn
<d5d35> DW_AT_low_pc : 0x8a4c0
<d5d3d> DW_AT_high_pc : 408
<d5d3f> DW_AT_stmt_list : 0x68ec1
The important thing here is the DW_AT_name, which is just "dlmopen.c".
The gdb.base/dlmopen.exp test also has a source file called
"dlmopen.c".
The dlmopen.exp test makes use of the clean_restart TCL proc, which
calls gdb_reinitialize_dir, which resets the source directories search
path to '$cdir:$cwd', and then prepends the test source directory to
the front of the list, so the source directory search path will look
something like:
/tmp/src/gdb/testsuite/gdb.base/gdb.base:$cdir:$cwd
In the existing test we try to place a breakpoint on 'dlmopen.c:64'.
This is the line tagged 'bp.main' in the source file. This currently
works fine. GDB searches through the symtabs and finds two matches,
the test dlmopen.c, and the glibc dlmopen.c. For each GDB tries to
convert line 64 into an address.
For the testsuite source file this is fine, we get the address of the
line tagged 'bp.main' from the source, and the breakpoint is created.
For the glibc source file though, at least, for the version available
to me, line 64 happens to be the closing '}' of a function, and there
isn't a line table entry for this exact line. So GDB searches forward
looking for the next line in order to place a breakpoint there. The
next line GDB finds is the start of the next function, and so GDB
rejects this location due to commit:
commit dcaa85e58c
Date: Wed May 1 10:47:47 2024 +0100
gdb: reject inserting breakpoints between functions
So we managed to avoid creating two breakpoint locations in this case,
but only by pure good luck.
In my updates to the test though I try to create a breakpoint at line
61 in addition to the breakpoint at line 64. So now the breakpoint
spec is 'dlmopen.c:61'.
Just as before, GDB identifies the 'dlmopen.c' could mean two files,
and searches for line 61 in both. The test source works as expected
and the breakpoint is created in the desired location.
But this time, line 61 in the glibc source file is an actual line,
with actual code, and so GDB places a breakpoint at this location.
This second breakpoint, in glibc is entirely unexpected (by the
dlmopen.exp test script). Unfortunately, the inferior hits this
second glibc breakpoint before it hits the actual breakpoint within
the main test executable, this throws the test off and causes some
failures.
In trying to fix this, I did wonder if I could just specify the full
path to the source file, instead of using just 'dlmopen.c:61'.
However, this doesn't work.
Remember that the glibc source file is recorded as just 'dlmopen.c'.
So, when GDB tries to figure out the absolute path to this source
file, the source directory search path is used. In this case, the
first entry in the source directory search path is the gdb.base/
directory in the GDB source tree. GDB looks in this directory and
finds a dlmopen.c, and so GDB assumes that this is the file in
question.
Thus, GDB actually thinks that both files _are_ the same source file.
Indeed, when GDB stops at the incorrect (glibc) breakpoint, and lists
the source code, it actually lists the source code from the correct
file. This confused me to begin with, GDB reported the wrong
function (the glibc function), but listed code from the correct file
and line.
Now on my machine I have installed the package that provides the glibc
source code. If I change the source directory search path so that
$cdir is first instead of the gdb.base/ from the GDB source tree, this
fixes the listing the wrong file problem. GDB does not realise that
the files are different, and if I create the breakpoint using the
absolute path then only a single breakpoint location is created.
However, this relies on the developer having both the glibc debug
information, and the glibc source package installed, this doesn't seem
like a great requirement to have in place.
So instead, I propose that we just take the easy way out, rename the
test source file. By doing this all the issues are avoided. The test
now creates a breakpoint at 'dlmopen-main.c:61', and there is only one
file with this name found, so we only get a single breakpoint location
created.
I renamed the source file, but not the dlmopen.exp file because the
test already makes use of multiple source files, so having a range of
different names didn't feel that bad, but if this bothers people, I
could rename both the .exp and main .c file, just let me know.
If you want to explore this issue for yourself then try with
installing the glibc debug information for your system, and ensure
that your GDBs under test are able to find the glibc debug
information. You can then either apply the series I linked above, or,
you can modify the existing test source so that the line tagged as
'bp.main' becomes line 61, I just deleted 3 lines from the big comment
at the head of the file.
Of course, reproducing this does depend on how glibc is compiled,
which could change from system to system, or overtime. I reproduced
this issue on Fedora 39 with glibc-2.38-19.
With this patch applied I no longer see any regressions when I apply
the above linked series.
While making these changes I took the opportunity to update the test
script to make better use of standard_testfile and build_executable.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
