Matthieu Longo [Mon, 28 Oct 2024 13:59:55 +0000 (13:59 +0000)]
aarch64: move tests for AArch64 protections (BTI, PAC) into a subfolder
- moved all the BTI and PAC tests into a new subfolder: "protections".
bti-far-*
bti-plt-*
bti-pac-plt-*
- move several procedures used only for AArch64 linker tests to a new exp
library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib.
- use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp.
Andrew Burgess [Tue, 19 Nov 2024 21:43:06 +0000 (21:43 +0000)]
gdb: handle DW_AT_entry_pc pointing at an empty sub-range
The test gdb.cp/step-and-next-inline.exp creates a test binary called
step-and-next-inline-no-header. This test includes a function
`tree_check` which is inlined 3 times.
When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1)
we see the following DWARF representing one of the inline instances of
tree_check:
Notice that one of the sub-ranges of tree-check is empty, this is the
line marked 'start == end'. As the end address is the first address
after the range, this range cover absolutely no code.
But notice too that the DW_AT_entry_pc for the inline instance points
at this empty range.
Further, notice that despite the ordering of the sub-ranges, the empty
range is actually in the middle of the region defined by the lowest
address to the highest address. The ordering is not a problem, the
DWARF spec doesn't require that ranges be in any particular order.
However, this empty range is causing issues with GDB newly acquire
DW_AT_entry_pc support.
GDB already rejects, and has done for a long time, empty sub-ranges,
after all, the DWARF spec is clear that such a range covers no code.
The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which
was outside of the low/high bounds of a block.
But in this case, the entry-pc value is within the bounds of a block,
it's just not within any useful sub-range. As a consequence, GDB is
storing the entry-pc value, and making use of it, but when GDB stops,
and tries to work out which block the inferior is in, it fails to spot
that the inferior is within tree_check, and instead reports the
function into which tree_check was inlined.
I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with
these versions gcc is still generating the empty sub-range, but now
this empty sub-range is no longer the entry point. Here's the
corresponding ranges table from gcc 14.2.0:
The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range,
as a result, when GDB stops at the entry-pc, GDB will correctly spot
that the inferior is in the tree_check function.
The fix I propose here is, instead of rejecting entry-pc values that
are outside the block's low/high range, instead reject entry-pc values
that are not inside any of the block's sub-ranges.
Now, GDB will ignore the prescribed entry-pc, and will instead select
a suitable default entry-pc based on either the block's low-pc value,
or the first address of the first range.
I have extended the gdb.cp/step-and-next-inline.exp test to check this
case, but this does depend on the compiler version being used (newer
compilers will always pass, even without the fix).
So I have also added a DWARF assembler test to cover this case.
Jan Beulich [Mon, 2 Dec 2024 08:38:47 +0000 (09:38 +0100)]
x86: always set ISA_1_BASELINE property for 64-bit objects
The baseline was, afaik, specifically chosen to align with the baseline
ISA of x86-64. It therefore makes no sense to emit that property only
conditionally; if anything it confuses tools analyzing the difference
between generated object files, which may result from just
added / changed / removed (entirely ISA-independent) code, without any
change to the enabled extensions. Compilers, after all, are free to use
these baseline "extensions" when generating 64-bit code.
While changing the one testcase that needs adjustment, also correct its
misleading name (to be in sync with the filename).
Jan Beulich [Mon, 2 Dec 2024 08:38:15 +0000 (09:38 +0100)]
x86/COFF: support section-index relocations in insn operands
On the grounds of the principle put down near the bottom of [1], along
with image and section relative operations, let's also support as insn
operands what .secidx is for on the data side (of course like elsewhere
the reloc operator can then also be used for data generation, albeit a
small tweak to x86_cons() is needed for this to work).
Jan Beulich [Mon, 2 Dec 2024 08:37:34 +0000 (09:37 +0100)]
x86/COFF: support RVA (image-relative) relocations in insn operands
As was pointed out in [1] compilers produce code using such constructs,
and hence we'd better support this. In analogy to the .rva directive
permit @rva to be used for this, and in analogy with other architectures
(plus to not diverge from e.g. Clang's integrated assembler, albeit I
haven't been able myself to confirm it knows this form) also permit
@imgrel.
While there also adjust the operand type specifier for the adjacent
@secrel32 - 64-bit fields cannot be used with a 32-bit relocation.
Further while there also deal with *-*-pe* in x86-64.exp, even if (right
now) perhaps only for completeness.
to fix 'no return statement' compiler warnings, e.g.:
process-exit-status-is-leader-exit-status.c: In function ‘start’:
process-exit-status-is-leader-exit-status.c:46:1: warning: no return
statement in function returning non-void [-Wreturn-type]
46 | }
| ^
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Fix more potential buffer overflows, and correct trad-code.c and
cisco-core.c where they should be using bfd_{z}alloc rather than
bfd_{z}malloc. To stop buffer overflows with fuzzed objects that
don't have a terminator on the core_file_failing_command string, this
patch allocates an extra byte at the end of the entire header buffer
rather than poking a NUL at the end of the name array (u_comm[] or
similar) because (a) it's better to not overwrite the file data, and
(b) it is possible that some core files make use of fields in struct
user beyond the end of u_comm to extend the command name. The patch
also changes some unnecessary uses of bfd_zalloc to bfd_alloc.
There's not much point in clearing memeory that will shortly be
completely overwritten.
PR 32399
* aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to
ensure the core_file_failing_command string is terminated.
* netbsd-core.c (netbsd_core_file_p): Likewise.
* ptrace-core.c (ptrace_unix_core_file_p): Likewise.
* rs6000-core.c (rs6000coff_core_p): Likewise.
* trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc
tdata rather than bfd_zmalloc.
* cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata.
oltolm [Fri, 29 Nov 2024 21:02:07 +0000 (22:02 +0100)]
Remove more remnants of old Mach-O workaround
Remove another adjustment for section address, this time for the
offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by
fetch_indexed_string.
Jens Remus [Fri, 29 Nov 2024 15:52:13 +0000 (16:52 +0100)]
s390: Fix linker test TLS -fpic and -fno-pic exec transitions
Commit 36bbf8646c8b ("s390: Treat addressing operand sequence as one in
disassembler") changed how plain "nop" gets disassembled and missed to
update any affected linker tests accordingly.
ld/testsuite/
* ld-s390/tlsbin.dd: "nop" disassembles into "nop".
Fixes: 36bbf8646c8b ("s390: Treat addressing operand sequence as one in disassembler") Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Treat addressing operand sequence as one in disassembler
Reuse logic introduced with the preceding commit in the assembler to
treat addressing operand sequences D(X,B), D(B), and D(L,B) as one
with regards to optional last operands (i.e. optparm and optparm2).
With this "nop" now disassembles into "nop" instead of "nop 0".
opcodes/
* s390-dis.c (operand_count): New helper to count the remaining
operands, treating D(X,B), D(B), and D(L,B) as one.
(skip_optargs_p): New helper to test whether remaining operands
are optional.
(skip_optargs_zero_p): New helper to test whether remaining
operands are optional and their values are zero.
(s390_print_insn_with_opcode): Use skip_optargs_zero_p to skip
optional last operands with a value of zero.
gas/testsuite/
* gas/s390/zarch-optargs.d (nop): Adjust test case accordingly.
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Treat addressing operand sequence as one in assembler
The assembler erroneously treated any number of operands as optional,
if the instruction was flagged to have one or two optional operands
(i.e. optparm or optparm2).
Only treat the exact specified number of operands as optional while
treating addressing operand sequences D(X,B), D(B), and D(L,B) as one
operand.
gas/
* config/tc-s390.c (operand_count): New helper to count the
remaining operands, treating D(X,B), D(B), and D(L,B) as one.
(skip_optargs_p): Use new helper operand_count to treat
D(X,B), D(B), and D(L,B) as one operand.
(md_gather_operands): Use skip_optargs_p to skip only the
optional last operands.
Jens Remus [Fri, 29 Nov 2024 14:37:19 +0000 (15:37 +0100)]
s390: Fix disassembly of optional addressing operands
"nop D1(B1)" erroneously disassembled into "nop D1(B1" (missing
closing parenthesis). "nop D1(X1,0)" and "nop D1(X1,)" erroneously
disassembled into "nop D1(X1)" (missing zero base register) instead
of "nop D1(X1,0)".
Do not skip disassembly of optional operands if they are index (X)
or base (B) registers or length (L) in an addressing operand sequence
"D(X,B)", "D(B)", or "D(L,B). Index and base register operand values
of zero are being handled separately, as they may not be omitted
unconditionally. For instance a base register value of zero must be
printed in above mentioned case, to distinguish the index from the
base register. This also ensures proper formatting of addressing
operand sequences.
While at it add further test cases for instructions with optional
operands.
opcodes/
* s390-dis.c (s390_print_insn_with_opcode): Do not
unconditionally skip disassembly of optional operands with a
value of zero, if within an addressing operand sequence.
gas/testsuite/
* gas/s390/zarch-optargs.d: Add further test cases for
instructions with optional operands.
* gas/s390/zarch-optargs.s: Likewise.
Jan Beulich [Fri, 29 Nov 2024 08:37:13 +0000 (09:37 +0100)]
x86/Solaris: support Sun form of CMOVcc
Sun specifies an alternative form for CMOVcc [1], which for some reason
we never cared to support, even if - as per gcc's configure checking for
it - it may have been the only permitted form at some point.
While documentation doesn't indicate FCMOVcc to have similar alternative
forms, gcc assumes so. Hence cover FCMOVcc as well.
Assorted targets do not check, as the ELF targets do, that the program
name in a core file is NUL terminated. Fix some of them. I haven't
attempted to fix all targets because editing host specific code can
easily result in build bugs, which aren't discovered until someone
build binutils for that host. (Of the files edited here, I can't
easily compile hpux-core.c and osf-core.c on a linux system.)
In commit 58776901074 ("[gdb/syscalls] Update to linux v6.11") I updated to
linux v6.11, but a recent submission for loongarch [1] used a current trunk
version, so it makes sense to do this as well elsewhere.
Using linux current trunk with update-linux-from-src.sh gets us 4 more
syscalls:
- setxattrat
- getxattrat
- listxattrat
- removexattrat
Guinevere Larsen [Mon, 25 Nov 2024 18:15:36 +0000 (15:15 -0300)]
gdb/testsuite: skip gdb.threads/omp-par-scope.exp with clang
Since 2020 it has been reported to clang[1] that the debug information
around OpenMP is insufficient. The OpenMP section is not declared
within the correct scope, and instead clang marks as if the section was
a function in the global scope. This causes several failures in the
test gdb.threads/omp-par-scope.exp when using clang to test GDB.
Since this isn't a true failure of GDB, and there is little expectation
that clang will be able to fix this soon, this commit disables the
aforementioned test when clang is being used.
Tom de Vries [Wed, 27 Nov 2024 17:48:43 +0000 (18:48 +0100)]
[gdb/symtab] Fix parent map dump
Before the fix for PR symtab/32225, the parent map dump showed a mapping from
section offsets to cooked index entries:
...
0x0000000000000035 0x3ba9560 (0x34: sp1::A)
...
but now that's no longer the case:
...
0x00000000406f5405 0x410a04d0 (0x34: sp1::A)
...
Fix this by extending the annotation somewhat, such that we get:
...
map start:
0x0000000012c52405 0x135fd550
(section: .debug_info, offset: 0x35) -> (0x34: sp1::A)
...
[gdb/symtab] Fix parent map when handling .debug_info and .debug_types
Consider test-case:
...
$ cat test.c
namespace sp1 {
class A {
int i;
const int f1 = 1;
...
const int f29 = 1;
};
}
sp1::A a;
void _start (void) {}
$ cat test2.c
namespace sp2 {
class B {
float f;
const float f1 = 1;
...
const float f29 = 1;
};
}
sp2::B b;
...
compiled like this:
...
$ g++ test.c -gdwarf-4 -c -g -fdebug-types-section
$ g++ test2.c -gdwarf-5 -c -g -fdebug-types-section
$ g++ -g test.o test2.o -nostdlib
...
Using:
...
$ gdb -q -batch -iex "maint set worker-threads 0" a.out -ex "maint print objfiles"
...
we get a cooked index entry with incorrect parent:
...
[29] ((cooked_index_entry *) 0x3c57d1a0)
name: B
canonical: B
qualified: sp1::A::B
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x154
parent: ((cooked_index_entry *) 0x3c57d110) [A]
...
The problem is that the parent map assumes that all offsets are in the same
section.
Fix this by using dwarf2_section_info::buffer-relative addresses instead,
which get us instead:
...
[29] ((cooked_index_entry *) 0x3f0962b0)
name: B
canonical: B
qualified: sp2::B
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x154
parent: ((cooked_index_entry *) 0x3f096280) [sp2]
...
Sandra Loosemore [Tue, 26 Nov 2024 19:13:07 +0000 (19:13 +0000)]
nios2: Remove binutils support for Nios II target.
The Nios II architecture has been EOL'ed by the vendor. This patch
removes all binutils, bfd, gas, binutils, and opcodes support for this
target with the exception of the readelf utility. (The ELF EM_*
number remains valid and the relocation definitions from the Nios II
ABI will never change in future, so retaining the readelf support
seems consistent with its purpose as a utility that tries to parse the
headers in any ELF file provided as an argument regardless of target.)
Sandra Loosemore [Tue, 26 Nov 2024 19:13:07 +0000 (19:13 +0000)]
nios2: Remove all GDB support for Nios II targets.
Intel has EOL'ed the Nios II architecture, and it's time to remove support
from all toolchain components before it gets any more bit-rotten from
lack of maintenance or regular testing.
Alan Modra [Mon, 25 Nov 2024 21:54:19 +0000 (08:24 +1030)]
PR32387 ppc64 TLS optimization bug with -fno-plt code
The inline plt code emitted by gcc is incompatible with the
linker/ld.so --tls-get-addr-optimize scheme. This is the runtime
optimisation where the first call to __tls_get_addr results in
__tls_get_addr updating the tls_index pair, then the special linker
stub using that to short-circuit second and subsequent calls for a
given tls symbol. Enabled by default when the linker sees
__tls_get_addr_opt is preseent, and enabled in ld.so when DT_PPC64_OPT
has PPC64_OPT_TLS set. Note that this is distinct from link-time tls
optimisation.
PR 32387
* elf64-ppc.c (ppc64_elf_check_relocs): Disable tls_get_addr_opt
on detecting inline plt calls to __tls_get_addr.
Tom de Vries [Tue, 26 Nov 2024 09:02:37 +0000 (10:02 +0100)]
[gdb/syscalls] Sync with strace v6.12
I ran gdb/syscalls/update-linux-defaults.sh with strace sources v6.12, and got
one difference in gdb/syscalls/linux-defaults.xml.in:
...
+ <syscall name="mseal" groups="memory"/>
...
Rerun make to propagate this change to the xml files.
Tom de Vries [Tue, 26 Nov 2024 08:49:29 +0000 (09:49 +0100)]
[gdb/syscalls] Use update-linux-from-src.sh for arm-linux
I tried to use arm-linux.py to regenerate arm-linux.xml.in, but it didn't work.
Fix this by:
- adding handling of arm-linux.xml.in in update-linux-from-src.sh,
- regenerating arm-linux.xml.in using update-linux-from-src.sh and linux 6.11
sources,
- regenerating arm-linux.xml using make, and
- removing arm-linux.py.
This changes the name "oldolduname" into "olduname".
Tom de Vries [Tue, 26 Nov 2024 08:49:29 +0000 (09:49 +0100)]
[gdb/syscalls] Improve update-linux-from-src.sh
Some improvements in gdb/syscalls/update-linux-from-src.sh:
- use bash instead of sh
- use local to distinguish between local and global vars
(which brings to light that pre uses the global rather than the local
start_date)
- factor out main and parse_args
- factor out regen
- iterate over *.xml.in instead of *.in
Tested on aarch64-linux. Verified with shellcheck.
Simon Marchi [Mon, 4 Nov 2024 18:27:51 +0000 (13:27 -0500)]
Convert all_bfds to new hash table
This converts gdb_bfd.c to use the new hash table for all_bfds.
This patch slightly changes the htab_t pretty-printer test, which was
relying on all_bfds. Note that with the new hash table, gdb-specific
printers aren't needed; the libstdc++ printers suffice -- in fact,
they are better, because the true types of the contents are available.
Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:50 +0000 (13:27 -0500)]
Convert typedef hash to new hash table
This converts the typedef hash to use the new hash table.
This patch found a latent bug in the typedef code. Previously, the
hash function looked at the type name, but the hash equality function
used types_equal -- but that strips typedefs, meaning that equality of
types did not imply equality of hashes. This patch fixes the problem
and updates the relevant test.
Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:47 +0000 (13:27 -0500)]
Convert gnu-v3-abi.c to new hash table
This converts gnu-v3-abi.c to use the new hash table.
This change shows how a std::vector can easily be made directly from
the hash table, simplifying the earlier approach of constructing a
vector and a hash table at the same time.
Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:38 +0000 (13:27 -0500)]
Convert linespec.c to new hash table
This converts linespec.c to use the new hash table.
Note that more simplification could perhaps be done. Currently, the
collectors in this code insert an element into a set and then, if the
element has not been seen before, append it to a vector. If we know
the order does not matter, or if the results can be sorted later, we
could dispense with the vector. This would simplify the code some
more. (This technique is used in the vtable patch, later in this
series.)
Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:36 +0000 (13:27 -0500)]
Convert compile-c-symbols.c to new hash table
This converts compile-c-symbols.c to use the new hash table.
I made it use a set of string_view instead of a set of `symbol *`, to
avoid calling `symbol::natural_name` over and over. This appears safe
to do, since I don't expect the storage behing the natural names to
change during the lifetime of the map.
Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:35 +0000 (13:27 -0500)]
gdbsupport: add unordered_dense.h 4.4.0
Add a copy of unordered_dense.h from [1]. This file implements an
efficient hash map and hash set with a nice C++ interface (a near
drop-in for std::unordered_map and std::unordered_set). This is
expected to be used to replace uses of `htab_t`, for improved code
readability and type safety. Performance-wise, it is preferred to the
std types (std::unordered_map and std::unordered_set) due to it using
open addressing vs closed addressing for the std types.
I chose this particular implementation because it is simple to use, it's
a standalone header and it typically performs well in benchmarks I have
seen (e.g. [2]). The license being MIT, my understanding is that it's
not a problem to use it and re-distribute it.
Add two additional files, gdbsupport/unordered_map.h and
gdbsupport/unordered_set.h, which make the map and set offered by
gdbsupport/unordered_dense.h available as gdb::unordered_map and
gdb::unordered_set.
Simon Marchi [Mon, 4 Nov 2024 18:27:32 +0000 (13:27 -0500)]
gdb: rename abbrev_cache to abbrev_table_cache
This cache holds `abbrev_table` objects, so I think it's clearer and
more consistent to name it `abbrev_table_cache`. Rename it and
everything that goes along with it.
Change-Id: I43448c0aa538dd2c3ae5efd2f7b3e7b827409d8c Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Mon, 11 Nov 2024 21:45:17 +0000 (21:45 +0000)]
gdb: do better in breakpoint_free_objfile
The breakpoint_free_objfile function is called from the objfile
destructor, and has the job of removing references to the soon to be
deleted objfile from all breakpoint locations.
The current implementation of breakpoint_free_objfile seems to miss
lots of possible objfile references within bp_location. Currently we
only check if bp_location::symtab is associated with the objfile in
question, but there's bp_location::section and bp_location::probe,
both of which might reference the soon to be deleted objfile.
Additionally bp_location::symbol and bp_location::msymbol if set will
surely be related to the objfile and should also be cleaned up.
I'm not aware that this causes any problems, but it doesn't seem like
a good idea to retain pointers to deleted state, so I propose that we
improve breakpoint_free_objfile to set these pointers back to nullptr.
In the future I plan to investigate the possibility of merging the
functionality of breakpoint_free_objfile into
disable_breakpoints_in_freed_objfile which is called via the
gdb::observers::free_objfile event. However, I already have a patch series
in progress which touches this area of GDB, and I'd like to avoid
conflicting with that earlier series:
Once this patch, and that earlier series have landed then I'll see if
I can merge breakpoint_free_objfile, but I don't think that this needs
to block this patch.
There should be no user visible changes after this commit.
Andrew Burgess [Tue, 5 Nov 2024 13:42:57 +0000 (13:42 +0000)]
gdb: remove an unnecessary scope block in update_breakpoint_locations
In update_breakpoint_locations there's a scope block which I don't
think adds any value. There is one local defined within the scope,
the local is currently an 'int' but should be a 'bool', either way
there's no destructor being triggered when we exit the scope.
This commit changes the local to a 'bool', removes the unnecessary
scope, and re-indents the code.
Within the (now removed) scope was a `for' loop. Inside the loop I
have converted this:
for (....)
{
if (CONDITION)
{
/* Body */
}
}
to this:
for (....)
{
if (!CONDITION)
continue;
/* Body */
}
which means that the body doesn't need to be indented as much, making
things easier to read.
There should be no functional change after this commit.
Reviewed-By: Klaus Gerlicher <klaus.gerlicher@intel.com>
Recalculate the checksum and replace whatever is at the end
of the packet with the newly calculated checksum. Then
replay the packet with the checksum added.
The motivation for this change is that I'd like to add a TCL test
which starts a communication with gdbsever setting the remotelog file.
Then, it modifies the remotelog, injects an error message instead of
the expected replay to some packet in order to test GDB reacts to
the error response properly.
Andrew Burgess [Tue, 5 Nov 2024 17:26:13 +0000 (17:26 +0000)]
gdb/testsuite: force TERM setting for some filename completion tests
Some of the filename completion tests perform mid-line completion.
That is we enter a partial line, then move the cursor back to the
middle of the line and perform completion.
The problem is that, emitting characters into the middle of a terminal
line relies on first emitting some control characters. And which
control characters are emitted will depend on the current TERM
setting.
When I initially added the mid-line completion tests I setup two
regexp that covered two different terminal types, but PR gdb/32338
identifies additional terminal types that emit different sequences of
control characters.
Rather than trying to handle all possible terminal types, lets just
force the TERM variable to something simple (i.e. "dumb") and then
just support that one case. The thing being tested for here was that
GDB would complete a filename in the middle of a line, the specific
terminal type was not really important.
I've simplified the regexp used to match the completion in two places,
and I now force TERM to be "dumb" for the mid-line completion tests.
I've tested this by setting my global environment TERM to 'ansi',
'xterm', 'xterm-mono', and 'dumb', and I see no failures in any mode
now.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32338 Tested-By: Tom de Vries <tdevries@suse.de>
Hui Li [Mon, 25 Nov 2024 07:50:42 +0000 (15:50 +0800)]
gdb: Add LoongArch process record/replay support in NEWS and doc
At present, process record/replay and reverse debugging has been
implemented on LoongArch. Update the NEWS and doc to record this
new change.
Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:46:00 +0000 (15:46 +0800)]
gdb: LoongArch: Add system call support for process record/replay
The process record and replay function also need record Linux
system call instruction. This patch adds LoongArch system call
number definitions in gdb/arch/loongarch-syscall.h, and adds
loongarch_linux_syscall_record() in gdb/loongarch-linux-tdep.c
to record system call execute log. With this patch, the main
functions of process record/replay and reverse debugging are
implemented.
The LoongArch system call numbers definitions are obtained from Linux kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/unistd.h
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/unistd.h
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full) Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:40:03 +0000 (15:40 +0800)]
gdb: LoongArch: Add basic process record/replay support
GDB provides a special process record and replay target that can
record a log of the process execution, and replay it later with
both forward and reverse execution commands. This patch adds the
basic support of process record and replay on LoongArch, it allows
users to debug basic LoongArch instructions and provides reverse
debugging support.
Here is a simple example on LoongArch:
$ cat test.c
int a = 0;
int main()
{
a = 1;
a = 2;
return 0;
}
$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:4
4 a = 1;
(gdb) record
(gdb) p a
$1 = 0
(gdb) n
5 a = 2;
(gdb) n
6 return 0;
(gdb) p a
$2 = 2
(gdb) rn
5 a = 2;
(gdb) rn
Reached end of recorded history; stopping.
Backward execution from here not possible.
main () at test.c:4
4 a = 1;
(gdb) p a
$3 = 0
(gdb) record stop
Process record is stopped and all execution logs are deleted.
(gdb) c
Continuing.
[Inferior 1 (process 129178) exited normally]
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full) Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:31:34 +0000 (15:31 +0800)]
gdb: LoongArch: Add instruction definition for process record
GDB provides a special process record function that can record a log
of the process execution. The core of this feature is need to record
the execution of all instructions. This patch adds opcode definitions
and judgments in gdb/arch/loongarch-insn.h. This is preparation for
later patch on LoongArch, there is no effect for the other archs with
this patch.
The LoongArch opcode and mask definitions are obtained from
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/loongarch-opc.c
LoongArch instruction description refer to the LoongArch Reference Manual:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom de Vries [Sun, 24 Nov 2024 08:21:28 +0000 (09:21 +0100)]
opcodes: fix Werror=format build breaker in opcodes/riscv-dis.c
I build gdb on arm-linux and ran into:
...
CC riscv-dis.lo
opcodes/riscv-dis.c: In function ‘print_insn_args’:
opcodes/riscv-dis.c:743:29: error: format ‘%lu’ expects argument of type \
‘long unsigned int’, but argument 4 has type ‘insn_t’ \
{aka ‘long long unsigned int’} [-Werror=format=]
743 | "%lu", EXTRACT_ZCMT_INDEX (l));
| ~~^
| |
| long unsigned int
| %llu
...
Fix this by printing the insn_t value, which is a uint64_t, using PRIu64.
Tom de Vries [Sat, 23 Nov 2024 12:07:38 +0000 (13:07 +0100)]
[gdb/contrib] Add two words to common-misspellings.txt
While reviewing changes generated by spellcheck.sh for directory sim, I
noticed two more misspellings:
...
arrithemetic->arithmetic
electricaly->electrically
...
Add them to common-misspellings.txt, and fix them in directory sim.
projects / thirdparty / binutils-gdb.git / log
