aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-10Move non-dependent gdb::observers::observable::visit_state outside templatePedro Alves1-15/+24
The other day, while looking at the symbols that end up in a GDB index, I noticed that the gdb::observers::observable::visit_state enum class appears a number of times: $ grep VISIT gdb-index-symbol-names.txt gdb::observers::observable<bpstat*, int>::visit_state::NOT_VISITED gdb::observers::observable<bpstat*, int>::visit_state::VISITED gdb::observers::observable<bpstat*, int>::visit_state::VISITING gdb::observers::observable<breakpoint*>::visit_state::NOT_VISITED gdb::observers::observable<breakpoint*>::visit_state::VISITED gdb::observers::observable<breakpoint*>::visit_state::VISITING gdb::observers::observable<char const*, char const*>::visit_state::NOT_VISITED gdb::observers::observable<char const*, char const*>::visit_state::VISITED gdb::observers::observable<char const*, char const*>::visit_state::VISITING gdb::observers::observable<char const*>::visit_state::NOT_VISITED gdb::observers::observable<char const*>::visit_state::VISITED gdb::observers::observable<char const*>::visit_state::VISITING gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::NOT_VISITED gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITED gdb::observers::observable<enum_flags<user_selected_what_flag> >::visit_state::VISITING gdb::observers::observable<frame_info*, int>::visit_state::NOT_VISITED gdb::observers::observable<frame_info*, int>::visit_state::VISITED gdb::observers::observable<frame_info*, int>::visit_state::VISITING gdb::observers::observable<gdbarch*>::visit_state::NOT_VISITED gdb::observers::observable<gdbarch*>::visit_state::VISITED gdb::observers::observable<gdbarch*>::visit_state::VISITING gdb::observers::observable<gdb_signal>::visit_state::NOT_VISITED gdb::observers::observable<gdb_signal>::visit_state::VISITED gdb::observers::observable<gdb_signal>::visit_state::VISITING [... snip ...] $ grep VISIT gdb-index-symbol-names.txt | wc -l 72 enum class visit_state is defined inside the class template observable, but it doesn't have to be, as it does not depend on the template parameters. This commit moves it out, so that only one such type exists. This reduces the size of a -O0 -g3 build for me by around 0.6%, like so: $ du -b gdb.before gdb.after 164685280 gdb.before 163707424 gdb.fixed and codesize by some 0.5%. Change-Id: I405f4ef27b8358fdd22158245b145d849b45658e
2022-05-10Fix compiling binutils/resbin.c with Clang version 14Nick Clifton1-5/+3
2022-05-09gprofng: include percentages in default metrics listVladimir Mezentsev1-2/+2
gprofng/ChangeLog 2022-05-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * src/gprofng.rc: Include percentages in default metrics list.
2022-05-10gprof: remove use of PTRAlan Modra6-22/+22
* basic_blocks.c: Replace uses of PTR with void * throughout. * cg_arcs.c: Likewise. * cg_print.c: Likewise. * hist.c: Likewise. * source.h: Likewise. * symtab.c: Likewise.
2022-05-10gas: remove use of PTRAlan Modra1-1/+1
* config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR.
2022-05-10opcodes: remove use of PTRAlan Modra6-6/+6
The non-cgen parts of opcodes. * cr16-dis.c (print_arg): Replace PTR with void *. * crx-dis.c (print_arg): Likewise. * rl78-dis.c (print_insn_rl78_common): Don't use PTR cast. * rx-dis.c (print_insn_rx): Likewise. * visium-dis.c (print_insn_visium): Likewise. * z8k-dis.c (print_insn_z8k): Likewise.
2022-05-10bfd: remove use of PTRAlan Modra6-11/+11
* coffcode.h (coff_write_object_contents): Don't cast to PTR. * elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR and PARAMS. (csky_allocate_dynrelocs): Don't use PTR cast. * elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace PTR with void *. * elf32-visium.c (visium_elf_howto_parity_reloc): Likewise. * elfxx-ia64.c (ia64_elf_reloc): Likewise. * plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise.
2022-05-10include: remove use of PTRAlan Modra1-2/+2
* hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *. (HTAB_DELETED_ENTRY): Likewise.
2022-05-10Automatic date update in version.inGDB Administrator1-1/+1
2022-05-09IBM zSystems: Accept (. - 0x100000000) PCRel32 operandsIlya Leoshkevich6-6/+26
as does not accept instructions like brasl %r0,.-0x100000000, because of two problems with the generic overflow check: 1. PCRel32 operands are signed, but are treated as unsigned. 2. The allowed range for these operands is [-(1 << 32), (1 << 32) - 1], and not [-(1 << 31), (1 << 31) - 1]. Fix both by disabling the generic overflow check - it's not needed, because s390_insert_operand () performs its own. gas/ * config/tc-s390.c (md_gather_operands): Set fx_no_overflow. * testsuite/gas/s390/s390.exp: Add zarch-z900-err. * testsuite/gas/s390/esa-z900.d: New test. * testsuite/gas/s390/esa-z900.s: New test. * testsuite/gas/s390/zarch-z900-err.l: New test. * testsuite/gas/s390/zarch-z900-err.s: New test.
2022-05-09gdb/testsuite: fix occasional failure in gdb.mi/mi-multi-commands.expAndrew Burgess1-1/+1
In bug PR gdb/29036, another failure was reported for the test gdb.mi/mi-multi-commands.exp. This test sends two commands to GDB as a single write, and then checks that both commands are executed. The problem that was encountered here is that the output of the first command, which looks like this: ^done,value="\"FIRST COMMAND\"" Is actually produced in parts, first the '^done' is printed, then the ',value="\"FIRST COMMAND\"" is printed. What was happening is that some characters from the second command were being echoed after the '^done' had been printed, but before the value part had been printed. To avoid this issue I've relaxed the pattern that checks for the first command a little. With this fix in place the occasional failure in this test is no longer showing up. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29036
2022-05-09[gdb] Update syscalls/{amd64,i386}-linux.xmlTom de Vries6-14/+470
- Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py. - Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and update-netbsd.sh). - Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in. - Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile. In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect: ... - <syscall name="madvise1" number="220"/> - <syscall name="getdents64" number="221"/> - <syscall name="fcntl64" number="222"/> + <syscall name="getdents64" number="220"/> + <syscall name="fcntl64" number="221"/> ... I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are correct. Tested on x86_64-linux.
2022-05-09[gdb] Add gdb/syscalls/MakefileTom de Vries2-0/+348
Add a Makefile in gdb/syscalls that can be used to translate gdb/syscalls/*.xml.in into gdb/syscalls/*.xml. Calling make reveals that bfin-linux.xml is missing, so add it. Tested on x86_64-linux.
2022-05-09gdb: LoongArch: Implement the return_value gdbarch methodTiezhu Yang1-0/+33
When execute the following command on LoongArch: make check-gdb TESTS="gdb.base/async.exp" there exist the following failed testcases: FAIL: gdb.base/async.exp: finish& (timeout) FAIL: gdb.base/async.exp: jump& (timeout) FAIL: gdb.base/async.exp: until& (timeout) FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error) we can see the following messages in gdb/testsuite/gdb.log: finish& Run till exit from #0 foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9 (gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. In order to fix the above failed testcases, implement the return_value gdbarch method on LoongArch. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-05-09gdb: fix for gdb.base/eof-exit.exp test failuresAndrew Burgess1-0/+18
This fix relates to PR gdb/29032, this makes the test more stable by ensuring that the Ctrl-D is only sent once the prompt has been displayed. This issue was also discussed on the mailing list here: https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html The problem identified in the bug report is that sometimes the Ctrl-D (that the test sends to GDB) arrives while GDB is processing a command. When this happens the Ctrl-D is handled differently than if the Ctrl-D is sent while GDB is waiting for input at a prompt. The original intent of the test was that the Ctrl-D be sent while GDB was waiting at a prompt, and that is the case the occurs most often, but, when the Ctrl-D arrives during command processing, then GDB will ignore the Ctrl-D, and the test will fail. This commit ensures the Ctrl-D is always sent while GDB is waiting at a prompt, which makes this test stable. But, that still leaves an open question, what should happen when the Ctrl-D arrives while GDB is processing a command? This commit doesn't attempt to answer that question, which is while bug PR gdb/29032 will not be closed once this commit is merged. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29032
2022-05-09[gdb] Make btrace maintainer entry more clearTom de Vries1-1/+2
Do: ... -record btrace <name> <email> +record + btrace <name> <email> ... to clarify that the listed maintainer is only maintainer of the btrace part of record.
2022-05-09ansidecl.h: sync from GCCMartin Liska1-20/+3
include/ChangeLog: * ansidecl.h: Sync from GCC.
2022-05-09[gdb/tdep] Support catch syscall pipe2 for i386Tom de Vries2-0/+2
With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run into: ... (gdb) catch syscall pipe2^M Unknown syscall name 'pipe2'.^M (gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2 ... Fix this by: - adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and - regenerating gdb/syscalls/i386-linux.xml using "xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in". Tested on x86_64-linux with native and unix/-m32. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
2022-05-09[gdb/testsuite] Handle pipe2 syscall in gdb.base/catch-syscall.expTom de Vries2-8/+64
When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed, I run into: ... (gdb) continue^M Continuing.^M ^M Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M (gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \ syscall pipe has returned ... The current glibc on Tumbleweed is 2.35, which contains commit "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2 is used instead of syscall pipe. Fix this by detecting whether syscall pipe or pipe2 is used before running the tests. Tested on x86_64-linux, specifically on: - openSUSE Tumbleweed (with glibc 2.35), and - openSUSE Leap 15.3 (with glibc 2.31). On openSUSE Tumbleweed + target board unix/-m32, this exposes: ... (gdb) catch syscall pipe2^M Unknown syscall name 'pipe2'.^M ... which will be fixed in a folllow-up patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
2022-05-09[gdb/tdep] Handle pipe2 syscall for amd64Tom de Vries2-0/+4
When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed, I run into: ... (gdb) continue^M Continuing.^M Process record and replay target doesn't support syscall number 293^M Process record: failed to record execution log.^M ^M Program stopped.^M 0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M (gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2 ... The current glibc on Tumbleweed is 2.35, which contains commit "linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2 is used in stead of syscall pipe. There is already support added for syscall pipe2 for aarch64 (which only has syscall pipe2, not syscall pipe), so enable the same for amd64, by: - adding amd64_sys_pipe2 in enum amd64_syscall - translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall Tested on x86_64-linux, specifically on: - openSUSE Tumbleweed (with glibc 2.35), and - openSUSE Leap 15.3 (with glibc 2.31). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29056
2022-05-09Automatic date update in version.inGDB Administrator1-1/+1
2022-05-08[gdb/testsuite] Fix gdb.tui/scroll.exp with read1Tom de Vries2-33/+74
When running test-case gdb.tui/scroll.exp, I get: ... Box Dump (80 x 8) @ (0, 0): 0 $17 = 16 1 (gdb) p 17 2 $18 = 17 3 (gdb) p 18 4 $19 = 18 5 (gdb) p 19 6 $20 = 19 7 (gdb) PASS: gdb.tui/scroll.exp: check cmd window in flip layout ... but with check-read1 I get instead: ... Box Dump (80 x 8) @ (0, 0): 0 (gdb) 15 1 (gdb) p 16 2 $17 = 16 3 (gdb) p 17 4 $18 = 17 5 (gdb) p 18 6 $19 = 18 7 (gdb) p 19 FAIL: gdb.tui/scroll.exp: check cmd window in flip layout ... The "p 19" command is handled by Term::command, which sends the command and then does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which: - matches the line with "(gdb) p 19", and - tries to match the following prompt "(gdb) " The problem is that scrolling results in reissuing output before the "(gdb) p 19", and the second matching triggers on that. Consequently, wait_for no longer translates gdb output into screen actions, and the screen does not reflect the result of "p 19". Fix this by using a new proc wait_for_region_contents, which in contrast to wait_for can handle a multi-line regexp. Tested on x86_64-linux with make targets check and check-read1.
2022-05-08[gdb/testsuite] Fix gdb.cp/casts.exp with -m32Tom de Vries1-1/+3
When running test-case gdb.cp/casts.exp with target board unix/-m32, I run into: ... (gdb) print (unsigned long long) &gd == gd_value^M $31 = false^M (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value ... With some additional printing, we can see in more detail why the comparison fails: ... (gdb) print /x &gd^M $31 = 0xffffc5c8^M (gdb) PASS: gdb.cp/casts.exp: print /x &gd print /x (unsigned long long)&gd^M $32 = 0xffffc5c8^M (gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd print /x gd_value^M $33 = 0xffffffffffffc5c8^M (gdb) PASS: gdb.cp/casts.exp: print /x gd_value print (unsigned long long) &gd == gd_value^M $34 = false^M (gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value ... The gd_value is set by this assignment: ... unsigned long long gd_value = (unsigned long long) &gd; ... The problem here is directly casting from a pointer to a non-pointer-sized integer. Fix this by adding an intermediate cast to std::uintptr_t. Tested on x86_64-linux with native and target board unix/-m32.
2022-05-08[gdb/testsuite] Handle init errors in gdb.mi/user-selected-context-sync.expTom de Vries1-3/+10
In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into: ... (gdb) builtin_spawn -pty^M new-ui mi /dev/pts/5^M New UI allocated^M (gdb) =thread-group-added,id="i1"^M (gdb) ERROR: MI channel failed warning: Error detected on fd 11^M thread 1.1^M Unknown thread 1.1.^M (gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \ test_cli_inferior: reset selection to thread 1.1 ... with many more UNRESOLVED following. The ERROR is a common problem, filed as https://sourceware.org/bugzilla/show_bug.cgi?id=28561 . But the many UNRESOLVEDs are due to not checking whether the setup as done in the test_setup function succeeds or not. Fix this by: - making test_setup return an error upon failure - handling test_setup error at the call site - adding a "setup done" pass/fail to be turned into an unresolved in case of error during setup. Tested on x86_64-linux, by manually triggering the error in mi_gdb_start_separate_mi_tty.
2022-05-08[gdb/testsuite] Fix gdb.ada/catch_ex_std.exp with remote-gdbserver-on-localhostTom de Vries1-0/+4
When running test-case gdb.ada/catch_ex_std.exp on target board remote-gdbserver-on-localhost, I run into: ... (gdb) continue^M Continuing.^M [Inferior 1 (process 15656) exited with code 0177]^M (gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main Remote debugging from host ::1, port 49780^M /home/vries/foo: error while loading shared libraries: libsome_package.so: \ cannot open shared object file: No such file or directory^M ... Fix this by adding the usual shared-library + remote-target helper "gdb_load_shlib $sofile". Tested on x86_64-linux with native and target board remote-gdbserver-on-localhost.
2022-05-08[gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with check-readmoreTom de Vries1-11/+7
When running test-case gdb.threads/fork-plus-threads.exp with check-readmore, I run into: ... [Inferior 11 (process 7029) exited normally]^M [Inferior 1 (process 6956) exited normally]^M FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \ inferior 1 exited (timeout) ... The problem is that the regexp consuming the "Inferior exited normally" messages: - consumes more than one of those messages at a time, but - counts only one of those messages. Fix this by adopting a line-by-line approach, which deals with those messages one at a time. Tested on x86_64-linux with native, check-read1 and check-readmore.
2022-05-08Automatic date update in version.inGDB Administrator1-1/+1
2022-05-07Fix "catch syscall"Tom Tromey1-4/+5
Simon pointed out that some recent patches of mine broke "catch syscall". Apparently I forgot to finish the conversion of this code when removing init_catchpoint. This patch completes the conversion and fixes the bug.
2022-05-07gdb/readline: fix extra 'quit' message problemAndrew Burgess2-2/+15
After these two commits: commit 4fb7bc4b147fd30b781ea2dad533956d0362295a Date: Mon Mar 7 13:49:21 2022 +0000 readline: back-port changes needed to properly detect EOF commit 91395d97d905c31ac38513e4aaedecb3b25e818f Date: Tue Feb 15 17:28:03 2022 +0000 gdb: handle bracketed-paste-mode and EOF correctly It was observed that, if a previous command is selected at the readline prompt using the up arrow key, then when the command is accepted (by pressing return) an unexpected 'quit' message will be printed by GDB. Here's an example session: (gdb) p 123 $1 = 123 (gdb) p 123 quit $2 = 123 (gdb) In this session the second 'p 123' was entered not by typing 'p 123', but by pressing the up arrow key to select the previous command. It is important that the up arrow key is used, typing Ctrl-p will not trigger the bug. The problem here appears to be readline's EOF detection when handling multi-character input sequences. I have raised this issue on the readline mailing list here: https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html a solution has been proposed here: https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html This patch includes a test for this issue as well as a back-port of (the important bits of) readline commit: commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1 Date: Wed May 4 11:18:04 2022 -0400 fix for setting RL_STATE_EOF in callback mode That commit also includes some updates to the readline documentation and tests that I have not included in this commit. With this commit in place the unexpected 'quit' messages are resolved.
2022-05-07Fix multiple ubsan warnings in i386-dis.cAlan Modra1-13/+13
Commit 39fb369834a3 "opcodes: Make i386-dis.c thread-safe" introduced a number of casts to bfd_signed_vma that cause undefined behaviour with a 32-bit libbfd. Revert those changes. * i386-dis.c (OP_E_memory): Do not cast disp to bfd_signed_vma for negation. (get32, get32s): Don't use bfd_signed_vma here.
2022-05-07Re: Fix new linker testsuite failures due to rwx segment test problemsAlan Modra2-5/+1
Fix it some more. bfd/ * elfnn-loongarch.c: Remove commented out elf_backend_* defines. ld/ * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Match arm*. Delete loongarch.
2022-05-07Automatic date update in version.inGDB Administrator1-1/+1
2022-05-06PowerPC fix for gdb.server/sysroot.expCarl Love1-1/+1
On PowerPC, the stop in the printf function is of the form: Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6 On other architectures the output looks like: Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6 The following patch modifies the printf test by matchine any character starting immediately after the printf. The test now works for PowerPC output as well as the output from other architectures. The test has been run on a Power 10 system and and Intel x86_64 system.
2022-05-06Fix new linker testsuite failures due to rwx segment test problemsNick Clifton3-1/+6
2022-05-06Introduce catchpoint classTom Tromey8-49/+49
This introduces a catchpoint class that is used as the base class for all catchpoints. init_catchpoint is rewritten to be a constructor instead. This changes the hierarchy a little -- some catchpoints now inherit from base_breakpoint whereas previously they did not. This isn't a problem, as long as re_set is redefined in catchpoint.
2022-05-06Add initializers to tracepointTom Tromey1-5/+5
This adds some initializers to tracepoint. I think right now these may not be needed, due to obscure rules about zero initialization. However, this will change in the next patch, and anyway it is clearer to be explicit.
2022-05-06Remove init_raw_breakpoint_without_locationTom Tromey9-72/+105
This removes init_raw_breakpoint_without_location, replacing it with a constructor on 'breakpoint' itself. The subclasses and callers are all updated.
2022-05-06Disable copying for breakpointTom Tromey1-0/+3
It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN. This patch does this.
2022-05-06Add constructor to exception_catchpointTom Tromey1-12/+13
This adds a constructor to exception_catchpoint and simplifies the caller.
2022-05-06Add constructor to syscall_catchpointTom Tromey1-2/+7
This adds a constructor to syscall_catchpoint and simplifies the caller.
2022-05-06Add constructor to signal_catchpointTom Tromey1-3/+8
This adds a constructor to signal_catchpoint and simplifies the caller.
2022-05-06Add constructor to solib_catchpointTom Tromey1-9/+12
This adds a constructor to solib_catchpoint and simplifies the caller.
2022-05-06Add constructor to fork_catchpointTom Tromey1-4/+7
This adds a constructor to fork_catchpoint and simplifies the caller.
2022-05-06Remove unnecessary line from catch_exec_command_1Tom Tromey1-1/+0
catch_exec_command_1 clears the new catchpoint's "exec_pathname" field, but this is already done by virtue of calling "new".
2022-05-06Constify breakpoint::print_recreateTom Tromey9-28/+28
This constifies breakpoint::print_recreate.
2022-05-06Constify breakpoint::print_mentionTom Tromey9-33/+33
This constifies breakpoint::print_mention.
2022-05-06Constify breakpoint::print_oneTom Tromey9-21/+21
This constifies breakpoint::print_one.
2022-05-06Constify breakpoint::print_itTom Tromey9-34/+32
This constifies breakpoint::print_it. Doing this pointed out some code in ada-lang.c that can be simplified a little as well.
2022-05-06Move works_in_software_mode to watchpointTom Tromey2-17/+11
works_in_software_mode is only useful for watchpoints. This patch moves it from breakpoint to watchpoint, and changes it to return bool.
2022-05-06Boolify breakpoint::explains_signalTom Tromey3-9/+9
This changes breakpoint::explains_signal to return bool.
generated by cgit v1.1 at 2025-02-23 17:27:42 +0000