| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice,
two adjacent 8-byte vars are written. For aarch64, we use a single stp
instruction for that.
If we do the same in function read_size8twice for two adjacent 8-byte var reads
using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
...
The same problem was observed for stp in PR tdep/29423, fixed by commit
9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64").
See that commit for an explanation of the hang.
That commit introduced max_access_size in aarch64_stopped_data_address:
...
The access size also can be larger than that of the watchpoint
itself. For instance, the access size of an stp instruction is 16.
So, if we use stp to store to address p, and set a watchpoint on
address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
RK3399 SOC). But it also can be p (observed on M1 SOC). Checking
for this situation introduces the possibility of false positives,
so we only do this for hw_write watchpoints. */
const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
...
If we say that hangs are worse than false positives, then we should also fix
this case.
Fix this by setting max_access_size to 16 for all watchpoint types.
Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
Extend the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice to also check read hardware watchpoints.
Tested on x86_64-linux.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
|
|
Improve the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice:
- move the code into a proc
- use -wrap
- use $decimal more often
- don't use gdb_test_multiple $test $test
- add comments
- start test when entering write_size8twice function, instead of main
- finish test when leaving write_size8twice function, instead of main
- add insn in between:
- insn triggering watchpoint, and
- insn triggering breakpoint
to ensure that the watchpoint triggers before the breakpoint, and
add a comment explaining this.
Tested on x86_64-linux.
|
|
This patch changes type::fields to return an array_view of the fields,
then fixes up the fallout.
More cleanups would be possible here (in particular in the field
initialization code) but I haven't done so.
The main motivation for this patch was to make it simpler to iterate
over the fields of a type.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Since linker never generates dynamic relocation for protected symbol in:
__attribute__((visibility("protected"))) int my_data;
int *
func (void)
{
return &my_data;
}
we should always treat protected symbols as local.
bfd/
PR ld/33260
* elfxx-x86.h (COPY_INPUT_RELOC_P): Always treat protected symbols
as local.
ld/
PR ld/33260
* testsuite/ld-i386/i386-export-class.rd: Updated.
* testsuite/ld-i386/i386-export-class.xd: Likewise.
* testsuite/ld-i386/i386.exp: Run pr33260-2.
* testsuite/ld-i386/pr33260-2.d: New file.
* testsuite/ld-i386/pr33260-2.s: Likewise.
* testsuite/ld-i386/pr33260.d: Remove "-z indirect-extern-access".
* testsuite/ld-x86-64/pr33260-x32.d: Likewise.
* testsuite/ld-x86-64/pr33260.d: Likewise.
* testsuite/ld-x86-64/pr33260-2-x32.d: New file.
* testsuite/ld-x86-64/pr33260-2.d: Likewise.
* testsuite/ld-x86-64/pr33260-2.s: Likewise.
* testsuite/ld-x86-64/x86-64-64-export-class.rd: Updated.
* testsuite/ld-x86-64/x86-64-x32-export-class.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run pr33260-2 and
pr33260-2-x32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
A buildbot pointed out that my changes to gdb.dap/scopes.exp caused a
test failure. The new code iterates over all the registers, fetching
their children (when possible). The failure comes because this code
failed to consider that a register might have "indexed" children,
which I believe can occur when a register is vector-like.
This patch fixes the problem by arranging to fetch indexed children
when indicated.
|
|
|
|
Add Linux/x86-64 support to export-class.exp by passing --32 to assembler
and passing -melf_i386 to linker.
* testsuite/ld-i386/export-class.exp: Run for Linux/x86-64.
Pass --32 to assembler. Pass -melf_i386 to linker.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
PR ld/24576
* testsuite/ld-scripts/pr24576-1.d: New.
* testsuite/ld-scripts/script.exp: Run pr24576-1.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
PR dap/33228 points out a failure that occurs when the DAP client
requests more children of a variable than actually exist. Currently,
gdb throws a somewhat confusing exception. This patch changes this
code to throw a DAPException instead, resulting in a more ordinary and
readable failure.
The spec seems to be silent on what to do in this case. I chose an
exception on the theory that it's easier to be strict now and lift the
restriction later (if needed) than vice versa.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
|
|
While investigating a different bug, I noticed that the DAP code would
report a "void *"-typed register as having children -- however,
requesting the children of this register would fail.
The issue here is that a plain "void *" can't be dereferenced. This
patch changes the default visualizer to treat a "void *" as a scalar.
This adds a new test; but also arranges to examine all the returned
registers -- this was the first thing I attempted and it seemed
reasonable to have a test that double-checks that all the registers
really can be dereferenced as appropriate.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
|
|
|
|
|
|
If all external symbol accesses are indirect, we can treat protected
symbols as local since there will be no copy relocation for data and
external function pointer access will go through GOT, instead of PLT.
No PLT slot should be used for external function pointer in executable.
bfd/
PR ld/33260
* elfxx-x86.h (COPY_INPUT_RELOC_P): Treat protected symbols with
indirect external access as local.
ld/
PR ld/33260
* testsuite/ld-i386/i386.exp: Run PR ld/33260 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr33260.d: New file.
* testsuite/ld-i386/pr33260.s: Likewise.
* testsuite/ld-x86-64/pr33260-x32.d: Likewise.
* testsuite/ld-x86-64/pr33260.d: Likewise.
* testsuite/ld-x86-64/pr33260.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Otherwise, the same test appears twice, once with PASS, once with UNSUPPORTED
on non-ia64. Just add '(ia64)' to the name so binutils.log is clearer.
* testsuite/binutils-all/testranges-ia64.d (#name): Add suffix.
|
|
Pass $plug_opt to nm when setting dump_prog to nm to load plugin.
PR binutils/21479
* testsuite/ld-plugin/lto-binutils.exp (run_lto_binutils_test):
Pass $plug_opt to nm.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
should_validate_memtags uses value_as_address to evalute
whether an address for a value is tagged. The comments for
that function simply say, "Extract a value as a C pointer."
While that sounds innoncuous, that function calls coerce_array,
which will dereference any references. This is not what is
desired here.
This can be demonstrated on an MTE-enabled host, such as aarch64-
based Ampere (example taken from tests introduced in this patch):
(gdb) p b.get_foo ()
Could not validate memory tag: Value can't be converted to integer.
$2 = (const foo &) @0xffffffffed88: {m_a = 42}
While the command completes, gdb didn't actually attempt to
evaluate any memory tags.
Fix this by using unpack_pointer instead.
Tested on x86_64 Fedora 40 and aarch64 RHEL 9.6.
|
|
With test-case gdb.tui/basic.exp and TERM=ansis, I run into (with some logging
added):
...
status line: '<reverse:1><intensity:dim>exec No process (asm) In:
L?? PC: ?? <reverse:0><intensity:normal>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
The status window uses ncurses attribute standout, which can differ between
different terminal settings.
Fix this by making the matching less strict.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/main-2.exp with TERM=ansis, I get:
...
screen line 6: 'B+><fg:black><intensity:bold> 21 <reverse:1><fg:default><intensity:normal> return 0;<reverse:0> '
FAIL: gdb.tui/main-2.exp: highlighted line in middle of source window
...
The test tries to check the highlighting of the source line, but also gets the
part with the line number, which makes it more complicated to parse.
Fix this by getting just the part with the source line:
...
screen line 6: '<reverse:1> return 0;<reverse:0> \
'
...
Tested on x86_64-linux.
|
|
While investigating using TERM=ansiw for freebsd, I also came across
TERM=ansis which unlike ansiw is present on both linux and freebsd.
Add initial support for TERM=ansi in tuiterm:
- handle ansis in Term::_have_bw
- add Term::_csi_x to support (well, ignore) DECREQTPARM
(Request Terminal Parameters)
This is sufficient to make the TUI testsuite pass on x86_64-freebsd.
|
|
The test-case gdb.tui/tui-layout-asm-short-prog.exp uses an assembly file
gdb.tui/tui-layout-asm-short-prog.S that it compiles using -nostdlib and
-nostartfiles.
However, on x86_64-linux the resulting executable still has dependencies on
libm and libc:
...
$ ldd outputs/gdb.tui/tui-layout-asm-short-prog/tui-layout-asm-short-prog
linux-vdso.so.1 (0x00007ffddf3ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8b13406000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8b13000000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8b1350f000)
...
due -lm being added by default_target_compile.
On x86_64-freebsd, using -nostdlib and -nostartfiles in combination with -lm
causes the compilation to fail.
Fix this by using -static as well.
Tested on x86_64-linux and x86_64-freebsd.
|
|
On x86_64-freebsd, with test-case gdb.base/exprs.exp I get:
...
(gdb) print 23
yydebug: state 0, reading 257 (INT)
yydebug: state 0, shifting to state 1
yydebug: state 1, reducing by rule 94 (exp : INT)
yydebug: after reduction, shifting from state 0 to state 59
yydebug: state 59, reading 0 (end-of-file)
yydebug: state 59, reducing by rule 7 (exp1 : exp)
yydebug: after reduction, shifting from state 0 to state 60
yydebug: state 60, reducing by rule 1 (start : exp1)
yydebug: after reduction, shifting from state 0 to state 58
$220 = 23
(gdb) FAIL: gdb.base/exprs.exp: print with debugging
...
The test fails because it's not finding the string "Starting parse".
In this case, the .y files are processed used byacc. I suppose the testcase
matches the case that bison is used.
Fix this by grepping for something more generic: shift or Shift.
Tested on x86_64-linux and x86_64-freebsd.
|
|
There's no reason to have the compiler materialize objects onto the
stack. And there's also no reason to allow comb[] and name_table[] to be
modifiable.
|
|
There's no reason for riscv_all_supported_ext[] to appear in libbfd.so's
dynamic symbol table. There's also no reason for various pieces of data
to live in .data, when .data.rel.ro or even .rodata can do.
|
|
... and const. There's no reason to have the compiler copy anonymous
objects onto the stack. And there's also no reason to allow the arrays
to be modifiable.
|
|
The custom parsing done there and in one of its callers allowed various
bogus constructs to be accepted. Insist on a non-zero leading digit when
parsing numbers, don't lose upper bits, and insist on proper separation
of operands.
|
|
The values are all pretty small; one is even a boolean. No point in
wasting 32 bits for every one of the fields.
|
|
To be a fair global name space citizen, give it an aarch64_ prefix. In
two cases, drop a variable that's used only once.
|
|
After updating the documentation in commit cf03713dd1c ("[gdb/cli] Document
\001 and \002 usage for set prompt"), I started to wonder if I could reproduce
the CLI issue described in PR cli/28887 using the TUI.
That turned out not to be the case, but I noticed handling of the markers in
tui_puts and tui_puts_internal, and no test-case exercising this, so I
decided to add this.
After doing so in gdb.tui/color-prompt.exp, I realized I could use the same
code to test the CLI case.
Add test-case gdb.base/color-prompt.exp that shares code with
gdb.tui/color-prompt.exp in gdb.tui/color-prompt.exp.tcl.
For the CLI case, I was hoping to reproduce the behaviour described in the PR,
but it didn't trigger.
FTR, I manually reproduced the behaviour and used script to record it. I
observed the following sequence after the C-a:
- ^M (CR) : go to start of line
- ^[[K (EL) : erase line
- ^M (CR) : go to start of line
- ^[[31m(gdb) ^[[0m : output prompt
- some long command : output text
- ^M (CR) : go to start of line
- ^[[C, 15 times (CUF): cursor forward 15 times
giving me:
...
(gdb) some long command
^
...
Perhaps we'll trigger this on some other os, or once we start using a
different TERM value.
Tested on x86_64-linux.
|
|
In ppc64_sysv_abi_return_value I came across this if clause:
...
/* Small character arrays are returned, right justified, in r3. */
if (valtype->code () == TYPE_CODE_ARRAY
&& !valtype->is_vector ()
&& valtype->length () <= 8
&& valtype->target_type ()->code () == TYPE_CODE_INT
&& valtype->target_type ()->length () == 1)
...
I decided to write a test-case to try and trigger this.
AFAIU, in C/C++, we're not allowed to return an array, so I wrote an Ada
test-case instead, with a function returning this type:
...
type T is new String (1 .. 4);
...
After doing so I realized that the clause above is not triggering because
valtype->target_type ()->code () == TYPE_CODE_CHAR. Fix this by allowing
both TYPE_CODE_INT and TYPE_CODE_CHAR.
Then I realized that the specific "small character array" handling comes from
the v1 abi. Add a check for this as well.
Tested on ppc64le-linux, with v2 abi.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
* ldlang.c: Don't include "elf-bfd.h" twice.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
It isn't needed anywhere except plugin.c. The typedef can disappear.
Also make a forward declaraion for ld_plugin_input_file in plugin.h
so that this header can be used without first including plugin-api.h.
bfd/
* plugin.h (struct ld_plugin_input_file): Forward declare.
(struct plugin_data_struct): Move to..
* plugin.c: ..here.
(add_symbols): Size plugin_data without using type.
* archive.c: Don't include plugin-api.h.
* elflink.c: Likewise.
* format.c: Likewise.
binutils/
* ar.c: Don't include plugin-api.h or ansidecl.h. Only
include plugin.h when BFD_SUPPORTS_PLUGINS.
* nm.c: Don't include plugin-api.h. Only include plugin.h
when BFD_SUPPORTS_PLUGINS.
* objcopy.c: Likewise.
ld/
* ldfile.c: Don't include plugin-api.h.
* ldmain.c: Likewise.
|
|
bfd/
* bfd.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
binutils/
* configure.ac: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
gas/
* acinclude.m4: Replace AC_TRY_LINK with AC_LINK_IFELSE.
Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
gprof/
* configure.ac: Replace AC_OUTPUT(file list) with
AC_CONFIG_FILES([file list])\nAC_OUTPUT.
libctf/
* configure.ac: Replace AC_TRY_LINK with AC_LINK_IFELSE.
opcodes/
* configure.ac: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
|
|
As defined by the enums amd64_regnum and i386_regnum the register
numbering starts at 0.
Defaults for register numbers are currently set to 0 which seems to
be the wrong default. Set them to -1 instead. Configure the right
register number if we find out it's supported in i386_gdbarch_init.
Similarly we don't have to set the num_*regname* variables to 0 in
i386_gdbarch_init, as it's already assigned to 0 by default.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Import the following commits from GCC as of r16-3056-gca2169c65bd169:
0d0837df697 libiberty: disable logging of list content for doubly-linked list tests
|
|
There's a logic error in loongarch_relax_perform_deletes: when there's
not any delete operation of which the start address is strictly smaller
than the symbol address, splay_tree_predecessor() will return nullptr
and the symbol size will be unchanged even if some bytes of it are
removed.
Make the logic more complete to fix this issue. Also factor out the
symbol size adjustment logic into a function to avoid code bloating.
Tested-by: WANG Xuerui <git@xen0n.name>
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
|
|
|
|
This reverts commit 14de1447c9c52c1bfc52588f8652836f66ac6c47.
An automated tester said that this patch caused a regression on
aarch64:
FAIL: gdb.arch/aarch64-atomic-inst.exp: Step through the ldxr/stxr sequence (timeout)
I looked into it a bit yesterday but couldn't see an obvious problem;
and it's somewhat of a pain to try to debug it at the moment.
Tom de Vries also noticed this and filed it in bugzilla. So, I'm
backing the patch out until I can port the failing test to the AdaCore
internal test suite in order to find out what went wrong.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33255
|
|
Fat IR objects contains both regular sections and IR sections. After
commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Sun May 4 05:12:46 2025 +0800
strip: Add GCC LTO IR support
"strip --strip-debug" no longer strips debug sections in fat IR objects
since fat IR objects are recognized as plugin object and copied as unknown
objects. Add a is_strip_input field to bfd to indicate called from strip.
Update bfd_check_format_matches not to treat archive member nor standalone
fat IR object as IR object so that strip can remove debug and IR sections
in fat IR object. For archive member, it is copied as an unknown object
if the plugin target is in use or it is a slim IR object. For standalone
fat IR object, it is copied as non-IR object.
bfd/
PR binutils/33246
* archive.c: Include "plugin-api.h" and "plugin.h" if plugin is
enabled.
(_bfd_compute_and_write_armap): Don't complain plugin is needed
when the plugin target is in use.
* bfd-in2.h: Regenerated.
* bfd.c (bfd): Add is_strip_input.
* format.c (bfd_set_lto_type): If there is .llvm.lto section,
set LTO type to lto_fat_ir_object.
(bfd_check_format_matches): Don't set LTO type when setting
format. When called from strip, don't treat archive member nor
standalone fat IR object as an IR object.
* plugin.c (bfd_plugin_get_symbols_in_object_only): Copy LTO
type derived from input sections.
nm/
PR binutils/33246
* nm.c (filter_symbols): Don't complain plugin is needed when
the plugin target is in use.
(display_rel_file): Likewise.
* objcopy.c (copy_archive): Set the BFD is_strip_input field of
archive member to 1 to indicate called from strip. Also copy
slim IR archive member as unknown object.
(copy_file): Set the BFD is_strip_input field of input bfd to
1 to indicate called from strip.
(strip_main): Keep .gnu.debuglto_* sections unless all GCC LTO
sections will be removed.
ld/
PR binutils/33246
* testsuite/ld-plugin/lto-binutils.exp (run_pr33246_test): New.
Run binutils/33246 tests with GCC and Clang.
* testsuite/ld-plugin/pr33246.c: New file.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Tidy changes to bfd_check_format_matches made by commit 9b854f169df9
which added a bfd_plugin_specified_p test and commit f752be8f916e
which added an lto_sections_removed arg. Both of these changes are
unnecessary if plugin_format is set to bfd_plugin_no before calling
bfd_check_format. bfd_plugin_no will prevent the plugin object_p
function from returning a match (and in the first case from a segfault
when loading plugins while a plugin is running). The plugin object_p
function already protected itself from recursive calls by setting
bfd_plugin_no before loading a plugin, but commit 9b854f169df9 opened
new bfds so they were unprotected.
It isn't strictly necessary to test for bfd_plugin_no in
bfd_check_format_matches but I kept the check to minimise functional
changes. Close inspection of the patch will notice I've added an
is_linker_input test too. That also isn't strictly necessary, I
think, but the match_count test was for the linker. See commit
999d6dff80fa.
PR 12291
PR 12430
PR 13298
PR 33198
bfd/
* format.c (bfd_check_format_lto): Revert to bfd_check_format.
(bfd_check_format_matches_lto): Revert to bfd_check_format_matches.
Correct comments. Manage both the lto_sections_removed and
bfd_plugin_specified_p cases by testing for bfd_plugin_no.
* plugin.c (bfd_plugin_get_symbols_in_object_only): Set
plugin_format to bfd_plugin_no before checking new bfds.
(try_load_plugin): Comment setting bfd_plugin_no.
(bfd_plugin_specified_p): Delete.
* plugin.h (bfd_plugin_specified_p): Delete.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Replace bfd_check_format_lto calls
with bfd_check_format using plugin_format set to bfd_plugin_no.
(check_format_object): New function.
(copy_file): Use it.
|
|
While trying out gccrs, I noticed that gdb_simple_compile does not use
the ".rs" extension for Rust sources. This patch fixes the problem,
which lets gccrs get a little further in the test suite.
|
|
Most code doesn't use cleanups any more, so remove the include of
cleanups.h from common-defs.h, and then only include that file where
it is truly needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The ANSI escape sequence translation layer in TUI mode strips italic
or underlined text modes silently. You cannot output text formatted
like that using `TuiWindow.write` in Python at the moment.
Parse the ANSI escape sequences for italic and underlined text into
the `ui_file_style` structure and apply it to the TUI window when
applying styles, similar to preserving the bold/dim state already.
A script like this shows italic and underlined text correctly now.
```python
import gdb
class TestTUIWindow:
_tui_window: gdb.TuiWindow
def __init__(self, tui_window: gdb.TuiWindow) -> None:
self._tui_window = tui_window
self._tui_window.title = "colors test"
def render(self) -> None:
self._tui_window.write("""
\x1b[4mThis is underlined.\x1b[24m And normal text.
\x1b[3mThis is italic.\x1b[23m And normal text.
""", True)
gdb.register_window_type("colortest", TestTUIWindow)
```
And launching it with
```
source the_above_script.py
tui new-layout test colortest 1 cmd 1
layout test
```
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
On x86_64-freebsd, with test-case gdb.base/style.exp I run into:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome"
(gdb) FAIL: $exp: colorsupport_8color: color support is 8 color
...
Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of
TERM=ansi for bsd, getting us instead:
...
(gdb) print $_colorsupport
[36;49;22;27m$1[m = "monochrome,ansi_8color"
(gdb) PASS: $exp: colorsupport_8color: color support is 8 color
...
Tested on x86_64-freebsd.
|
|
This patch gives gdbserver the ability to omit the 's' reply to
'vCont?'. This tells gdb that hardware single-step is definitely not
supported, causing it to fall back to using software single-step.
This is useful for testing the earlier change to
maybe_software_singlestep.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When the PikeOS osabi sniffer was added, Pedro suggested that a target
could omit stepping from its vCont? reply packet to tell gdb that
software single-step must be used:
https://sourceware.org/legacy-ml/gdb-patches/2018-09/msg00312.html
This patch implements this idea by moving the call to
target_can_do_single_step into maybe_software_singlestep.
I've also removed some FIXME comments from gdbarch_components.py, and
slightly updated the documentation for gdbarch_software_single_step.
I think these comments are somewhat obsolete now that
target_can_do_single_step exists -- the current approach isn't exactly
what the comments intended, but on the other hand, it exists and
works.
Following review comments from Andrew, this version changes
record-full to use maybe_software_singlestep, and then combines
maybe_software_singlestep with insert_single_step_breakpoint.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28440
|
