In a later commit I will add a Python API to access the 'maint packet'
functionality, that is, sending a user specified packet to the target.
To make implementing this easier, this commit refactors how this
command is currently implemented so that the packet_command function
is now global.
The new global send_remote_packet function takes an object that is an
implementation of an abstract interface. Two functions within this
interface are then called, one just before a packet is sent to the
remote target, and one when the reply has been received from the
remote target. Using an interface object in this way allows (1) for
the error checking to be done before the first callback is made, this
means we only print out what packet it being sent once we know we are
going to actually send it, and (2) we don't need to make a copy of the
reply if all we want to do is print it.
One user visible changes after this commit are the error
messages, which I've changed to be less 'maint packet' command
focused, this will make them (I hope) better for when
send_remote_packet can be called from Python code.
So: "command can only be used with remote target"
Becomes: "packets can only be sent to a remote target"
And: "remote-packet command requires packet text as argument"
Becomes: "a remote packet must not be empty"
Additionally, in this commit, I've added support for packet replies
that contain binary data. Before this commit, the code that printed
the reply treated the reply as a C string, it assumed that the string
only contained printable characters, and had a null character only at
the end.
One way to show the problem with this is if we try to read the auxv
data from a remote target, the auxv data is binary, so, before this
commit:
(gdb) target remote :54321
...
(gdb) maint packet qXfer:auxv:read::0,1000
sending: "qXfer:auxv:read::0,1000"
received: "l!"
(gdb)
And after this commit:
(gdb) target remote :54321
...
(gdb) maint packet qXfer:auxv:read::0,1000
sending: "qXfer:auxv:read::0,1000"
received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
(gdb)
The binary contents of the reply are now printed as escaped hex.
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
According the rvv spec,
https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc
The bits of vtype immediate from 8 to (xlen - 1) should be reserved.
Therefore, we should also dump the vtype immediate as numbers, when
they are set over 8-bits. I think this is a bug that we used to support
vediv extension and use the bit 8 and 9 of vtype, but forgot to update
the behavior when removing the vediv.
Consider the testcases,
vsetvli a0, a1, 0x700 # the reserved bit 10, 9 and 8 are used.
vsetvli a0, a1, 0x400 # the reserved bit 10 is used.
vsetvli a0, a1, 0x300 # the reserved bit 9 and 8 are used.
vsetvli a0, a1, 0x100 # the reserved bit 8 is used.
vsetivli a0, 0xb, 0x300 # the reserved bit 9 and 8 are used.
vsetivli a0, 0xb, 0x100 # the reserved bit 8 is used.
The original objdump shows the following result,
0000000000000000 <.text>:
0: 7005f557 vsetvli a0,a1,1792
4: 4005f557 vsetvli a0,a1,1024
8: 3005f557 vsetvli a0,a1,e8,m1,tu,mu
c: 1005f557 vsetvli a0,a1,e8,m1,tu,mu
10: f005f557 vsetivli a0,11,e8,m1,tu,mu
14: d005f557 vsetivli a0,11,e8,m1,tu,mu
But in fact the correct result should be,
0000000000000000 <.text>:
0: 7005f557 vsetvli a0,a1,1792
4: 4005f557 vsetvli a0,a1,1024
8: 3005f557 vsetvli a0,a1,768
c: 1005f557 vsetvli a0,a1,256
10: f005f557 vsetivli a0,11,768
14: d005f557 vsetivli a0,11,256
gas/
* testsuite/gas/riscv/vector-insns.d: Added testcases to
test the reserved bit 8 to (xlen-1) of vtype.
* testsuite/gas/riscv/vector-insns.s: Likewise.
include/
* opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES,
since they are different for operand Vc and Vb.
opcodes/
* riscv-dis.c (print_insn_args): Updated imm_vtype_res to
extract the reserved immediate of vtype correctly.
Consider the following case,
vsetvli a0, a1, 0x4 # unrecognized vlmul
vsetvli a0, a1, 0x20 # unrecognized vsew
vsetivli a0, 0xb, 0x4 # unrecognized vlmul
vsetivli a0, 0xb, 0x20 # unrecognized vsew
For the current dis-assembler, we get the result,
0000000000000000 <.text>:
0: 0045f557 vsetvli a0,a1,e8,(null),tu,mu
4: 0205f557 vsetvli a0,a1,e128,m1,tu,mu
8: c045f557 vsetivli a0,11,e8,(null),tu,mu
c: c205f557 vsetivli a0,11,e128,m1,tu,mu
The vsew e128 and vlmul (null) are preserved according to the spec,
so dump these fields looks wrong. Consider that we are used to dump
the unrecognized csr as csr numbers directly, we should also dump
the whole vset[i]vli immediates as numbers, once the vsew or vlmul
is reserved. Therefore, following is what I expected,
0000000000000000 <.text>:
0: 0045f557 vsetvli a0,a1,4
4: 0205f557 vsetvli a0,a1,32
8: c045f557 vsetivli a0,11,4
c: c205f557 vsetivli a0,11,32
gas/
* testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli
testcases since we should dump the immediate as numbers once
the vsew or vlmul is reserved.
* testsuite/gas/riscv/vector-insns.s: Likewise.
opcodes/
* riscv-dis.c (print_insn_args): The reserved vsew and vlmul
are NULL string in the riscv_vsew and riscv_vlmul, so dump the
whole imm as numbers once one of them is NULL.
* riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL.
(riscv_vlmul): Set the reserved vlmul to NULL.
The Rust compiler plans to change the encoding of a Rust 'char' type
to use DW_ATE_UTF. You can see the discussion here:
https://github.com/rust-lang/rust/pull/89887
However, this fails in gdb. I looked into this, and it turns out that
the handling of DW_ATE_UTF is currently fairly specific to C++. In
particular, the code here assumes the C++ type names, and it creates
an integer type.
This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
are signed in C++"). The message says:
Both places need fixing. But since I couldn't tell why dwarf2read.c
needs to create a new type, I've made it use the per-arch built-in
types instead, so that the types are only created once per arch
instead of once per objfile. That seems to work fine.
... which is fine, but it seems to me that it's also correct to make a
new character type; and this approach is better because it preserves
the type name as well. This does use more memory, but first we
shouldn't be too concerned about the memory use of types coming from
debuginfo; and second, if we are, we should implement type interning
anyway.
Changing this code to use a character type revealed a couple of
oddities in the C/C++ handling of TYPE_CODE_CHAR. This patch fixes
these as well.
I filed PR rust/28637 for this issue, so that this patch can be
backported to the gdb 11 branch.
During debuginfod downloads, ctrl-c should result in the download
being cancelled and skipped. However in some cases, ctrl-c fails to
get delivered to gdb during downloading. This can result in downloads
being unskippable.
Fix this by ensuring that target_terminal::ours is in effect for the
duration of each download.
Co-authored-by: Tom de Vries <tdevries@suse.de>
https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3
PR28539 describes a segfault in lambda function search_one_symtab due to
psymbol_functions::expand_symtabs_matching calling expansion_notify with a
nullptr symtab:
...
struct compunit_symtab *symtab =
psymtab_to_symtab (objfile, ps);
if (expansion_notify != NULL)
if (!expansion_notify (symtab))
return false;
...
This happens as follows. The partial symtab ps is a dwarf2_include_psymtab
for some header file:
...
(gdb) p ps.filename
$5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h"
...
The includer of ps is a shared symtab for a partial unit, with as user:
...
(gdb) p ps.includer().user.filename
$11 = 0x64fc9f0 \
"/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp"
...
The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently
the shared symtab), but returns nullptr because:
...
struct dwarf2_include_psymtab : public partial_symtab
{
...
compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override
{
return nullptr;
}
...
Fix this by returning the Decl.cpp symtab instead, which fixes the segfault
in the PR.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28539
Proc lines contains a typo:
...
string_form { set $_line_string_form $value }
...
Remove the incorrect '$' in '$_line_string_form'.
Tested on x86_64-linux.
While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
test-case generates all executables and associated temporary files using the
same filenames.
Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
test-case.
Tested on x86_64-linux.
When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
we run into another instance of PR28383, where the dwarf assembler generates
64-bit relocations which are not supported by the 32-bit assembler:
...
dw2-lines-dw.S: Assembler messages:^M
outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
cannot represent relocation type BFD_RELOC_64^M
...
Fix this by using _op_offset in _line_finalize_header.
Tested on x86_64-linux.
We'll rely on the toolchain probing to determine whether each arch's
tests can be run rather the current configure target. This allows
testing all of the ports in a multitarget configuration.
For now, we don't reformat the files entirely to make it easier to
review, and in case we need to make adjustments. Once this feels
like it's stable, we can flatten the code a bit by removing the if
statement entirely.
Break up the dejagnu logic so that we can parallelize the testsuite.
This takes a page from gcc & gdb where each .exp is run in isolation
instead of in serial.
For most targets, this doesn't make much of a difference as they only
have a single .exp. A few (like cris & frv) have multiple .exp though
and will see a bit of a speed up.
The real gain is when testing a multitarget build. This way we can
run all the targets in parallel and cut the execution time a bit.
On my system, it goes from ~155sec to ~100sec.
We can gain further speedups by splitting up some of the larger .exp
files into smaller groups. We'll do that in a followup though.
Leverage the new per-port toolchain settings to initialize the env
for eeach set of tests. This allows us to run all the tests in a
multitarget build if the user sets up the vars. If they don't, we
can still skip all the tests.
Gas does not support multitarget builds -- it still only supports
a single input & output format. ld is a bit better, but requires
manual flags to select the right output. This makes it impossible
to run the complete testsuite in a multitarget build.
To address this limitation, create a suite of FOR_TARGET variables
so these can be set to precompiled as & ld programs. It requires
a bit of setup ahead of time, but it's a one-time cost, and makes
running the full testsuite at once much easier.
Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
which can change the size of core types. Since these haven't been
unified across ports, add checks to make sure they aren't accidentally
included when building for all ports. This caught the sim-load file
using poisoned headers that it didn't actually need.
Now that we've unified all the syscall tables, this file does not rely
on any port-specific settings, so move it up to building as part of the
common step so we only do it once in a multibuild.
Now that all ports have switched to target-newlib-* files, there's
no need for these files & generating things at build time. So punt
the logic and make target-newlib-syscall a hard requirement.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and mcore has a custom syscall
table for its newlib/libgloss port.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and riscv has a custom syscall
table for its newlib/libgloss port.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and cr16 has a custom syscall
table for its newlib/libgloss port.
This allows cleaning up the syscall ifdef logic. We know these will
always exist now.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and d10v has a custom syscall
table for its newlib/libgloss port.
This allows cleaning up the syscall ifdef logic. We know these will
always exist now.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and sh has a custom syscall
table for its newlib/libgloss port.
Use the new target-newlib-syscall module. This is needed to merge all
the architectures into a single build, and v850 has a custom syscall
table for its newlib/libgloss port.
This allows cleaning up the syscall ifdef logic. We know these will
always exist now.
Use the new target-newlib-syscall.h to provide the target syscall
defines. These code paths are written specifically for the newlib
ABI rather than being generalized, so switching them to the defines
rather than trying to go through the dynamic callback conversion
seems like the best trade-off for now. Might have to reconsider
this in the future.
Like we just did for pulling out the errno map, pull out the syscall
maps into a dedicated common file. Most newlib ports are using the
same syscall map, but not all, which means we have to do a bit more
work to migrate.
This commit adds the maps and switches the ports using the common
default syscall table over to it. Ports using unique syscall tables
are still using the old targ-map.c logic.
Switching common ports over is easy by checking NL_TARGET, but the
ppc code needs a bit more cleanup here hence its larger diff.
Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.
Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.
The variable names used to restore CFLAGS and LDFLAGS here don't quite
match the names used above, resulting in losing the original CFLAGS and
LDFLAGS. Fix that.
Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a
As we setup more reliable CC_FOR_TARGET variables for each target, the
bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
can setup if they want to add custom options.
If the board info sets the sim to a basename that is found via $PATH
(which is the default dejagnu behavior), the logic here to use its
dirname to find rvdummy fails because it looks for `./rvdummy`. So
switch it to always use the local build of rvdummy which is the one
we want to be testing against in the first place.
If we get a request for testing against a different setup, we can
figure out & document the needs at that point, and then setup some
config knobs to control it.
In commit f8080fb7a4 "[gdb/testsuite] Add gdb.base/include-main.exp" a
file gdb.base/main.c was added, which caused the following regression:
...
(gdb) list^M
<gdb.base/main.c>
(gdb) FAIL: gdb.base/list-missing-source.exp: list
...
The problem is that the test-case does not expect to find a file main.c, but
now it finds gdb.base/main.c.
Fix this by using the more specific file name list-missing-source.c.
Tested on x86_64-linux.
Add missing $(EXEEXT) to dependencies on bits-gen. These are actually
build-only tools, but automake doesn't allow for build & host tools, so
the rules are re-using EXEEXT.
