aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-24Extra indent & extra lineusers/palves/info_breakpoints_improvementsPedro Alves1-7/+35
Comment out the "#define EXTRA_LINE" line to stop emitting the extra line. Change-Id: I174b00d956a0e1585269778570e0ed810906d68c
2022-05-23Introduce "info breakpoints -hide-locations"Pedro Alves12-78/+183
This commit adds a new option to "info breakpoints", "-hide-locations". It's purpose is to tell GDB to skip printing breakpoint locations, printing only the breakpoint header rows. And then, since only code breakpoint locations print anything in the "Address" column, "-hide-breakpoints" also disables the "Address" column. For example, when debugging GDB, you can use the new options to get this: (top-gdb) i b -h Num Type Disp Enb What 1 breakpoint keep y internal_error 2 breakpoint keep y info_command silent return 3 breakpoint keep y main breakpoint already hit 1 time 4 breakpoint keep y error (top-gdb) instead of: (top-gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y internal_error 1.1 y 0x0000555555f81d12 in internal_error(char const*, int, char const*, ...) at /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc:51 2 breakpoint keep y info_command silent return 2.1 y 0x00005555557b3097 in info_command(char const*, int) at /home/pedro/gdb/binutils-gdb/src/gdb/cli/cli-cmds.c:217 3 breakpoint keep y main breakpoint already hit 1 time 3.1 y 0x000055555564106c in main(int, char**) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:25 3.2 y 0x0000555555dba524 in selftests::string_view::capacity_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/capacity/1.cc:167 3.3 y 0x0000555555dba943 in selftests::string_view::cons_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/1.cc:62 3.4 y 0x0000555555dbaa34 in selftests::string_view::cons_2::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/2.cc:41 3.5 y 0x0000555555dbaa9a in selftests::string_view::cons_3::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/cons/char/3.cc:34 3.6 y 0x0000555555dbac6b in selftests::string_view::element_access_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/element_access/char/1.cc:66 3.7 y 0x0000555555dbac83 in selftests::string_view::element_access_empty::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/element_access/char/empty.cc:25 3.8 y 0x0000555555dbae91 in selftests::string_view::element_access_front_back::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/element_access/char/front_back.cc:38 3.9 y 0x0000555555dbb2bd in selftests::string_view::inserters_2::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/inserters/char/2.cc:84 3.10 y 0x0000555555dbb429 in selftests::string_view::modifiers_remove_prefix::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/modifiers/remove_prefix/char/1.cc:58 3.11 y 0x0000555555dbb575 in selftests::string_view::modifiers_remove_suffix::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/modifiers/remove_suffix/char/1.cc:58 3.12 y 0x0000555555dbbd38 in selftests::string_view::operations_compare_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/compare/char/1.cc:127 3.13 y 0x0000555555dbbe7b in selftests::string_view::operations_compare_13650::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/compare/char/13650.cc:45 3.14 y 0x0000555555dbbf6a in selftests::string_view::operations_copy_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/copy/char/1.cc:41 3.15 y 0x0000555555dbc03b in selftests::string_view::operations_data_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/data/char/1.cc:39 3.16 y 0x0000555555dbc5fe in selftests::string_view::operations_find_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/find/char/1.cc:160 3.17 y 0x0000555555dbcb60 in selftests::string_view::operations_find_2::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/find/char/2.cc:158 3.18 y 0x0000555555dbd1c1 in selftests::string_view::operations_find_3::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/find/char/3.cc:158 3.19 y 0x0000555555dbd26c in selftests::string_view::operations_find_4::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/find/char/4.cc:40 3.20 y 0x0000555555dbd83f in selftests::string_view::operations_rfind_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/1.cc:90 3.21 y 0x0000555555dbda98 in selftests::string_view::operations_rfind_2::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/2.cc:48 3.22 y 0x0000555555dbde4c in selftests::string_view::operations_rfind_3::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/rfind/char/3.cc:63 3.23 y 0x0000555555dbe189 in selftests::string_view::operations_substr_1::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operations/substr/char/1.cc:74 3.24 y 0x0000555555dbffdb in selftests::string_view::operators_2::main() at /home/pedro/gdb/binutils-gdb/src/gdb/unittests/basic_string_view/operators/char/2.cc:366 4 breakpoint keep y error 4.1 y 0x00005555557f5142 in gcc_c_plugin::error(char const*) const at /home/pedro/gdb/binutils-gdb/src/gdb/../include/gcc-c-fe.def:198 4.2 y 0x00005555557fe1f4 in gcc_cp_plugin::error(char const*) const at /home/pedro/gdb/binutils-gdb/src/gdb/../include/gcc-cp-fe.def:983 4.3 y 0x0000555555f81c5e in error(char const*, ...) at /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc:39 4.4 y 0x00007ffff65ee4e0 <icu_66::RBBIRuleScanner::error(UErrorCode)> 4.5 y 0x00007ffff685e070 <icu_66::RegexCompile::error(UErrorCode)> 4.6 y 0x00007ffff6cd4e86 in error at /usr/include/x86_64-linux-gnu/bits/error.h:40 4.7 y 0x00007ffff71c2190 in __error at error.c:274 Documentation change included. No testsuite changes yet until there's agreement on the previous patch. Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
2022-05-23Always show locations for breakpoints & show canonical location specPedro Alves4-202/+278
I've thought for a few years that "info breakpoints" should show BOTH the canonical location spec behind each breakpoint, and the actual resolved location(s) where the breakpoint is inserted. It currently only shows the latter. Here are for example 3 breakpoints that I set while debugging gdb: (top-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000575127 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 2 breakpoint keep y 0x0000000000575127 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3 breakpoint keep y <MULTIPLE> 3.1 y 0x0000000000575127 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3.2 y 0x00007ffff6d50410 in PyErr_SetObject at /usr/src/debug/python2-2.7.15-4.fc27.x86_64/Python/errors.c:54 (top-gdb) From looking at those, you have no idea how I created the breakpoints in the first place, which specs I used. Breakpoints 1 and 2 look like the same from that output, but really aren't. I'll have forgotten after a while which was which though. And what's with the third breakpoint, showing seemingly unrelated functions in its locations? GDB of course knows all those breakpoints were set differently. It needs to remember the location specs in order to re_set the locations properly. And it needs to remember the spec in order to save the breakpoints, like: (top-gdb) save breakpoints bpts.cmd Saved to file 'bpts.cmd'. Let's look at the file, see how the breakpoints had been created: (top-gdb) shell cat bpts.cmd break internal_error break -qualified internal_error break errors.c:54 (top-gdb) Ah, the "-qualified" information for breakpoint 2 was lost from "info breakpoints" output. And now it's obvious why we have two locations for breakpoint 3 -- that breakpoint was set by FILE:LINE, and GDB resolved that to two locations in unrelated functions that happen to be implemented in files with the same name. I propose that we show this info in "info breakpoints" too, with a conceptualy simple change that just removes special cases. To get there, let's observe a fact -- there are a couple cases where "info breakpoints" prints the breakpoint's locations in their own rows: #1 - when the breakpoint has multiple locations: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> 1.1 y 0x0000000000a2d874 in func(int) at func.c:51 1.2 y 0x0000000000b2d640 in func(int) at func2.c:51 #2 - when the breakpoint only has one location, but it is disabled, while the breakpoint itself is enabled. E.g.: (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000a2d874 in func(int) at func.c:51 (gdb) disable 1.1 (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> 1.1 n 0x0000000000a2d874 in func(int) at func.c:51 (the last example shows <MULTIPLE> when there's only one location, but let's ignore that...) Note that when we print the locations in a separate row, the "What" column for the breakpoint header row is empty. That seems to me to be the perfect spot to put the breakpoint's location spec. Then, if we make it such that breakpoints always print their locations in separate rows, even if they only have one location, that space is always there to use. The result for the confusing example at the top would be this: (top-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y internal_error 1.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 2 breakpoint keep y -qualified internal_error 2.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3 breakpoint keep y errors.c:54 3.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3.2 y 0x00007ffff6d50410 in PyErr_SetObject at /usr/src/debug/python2-2.7.15-4.fc27.x86_64/Python/errors.c:54 (Note: this looks better on a terminal with color.) Breakpoints would no longer move from single-location to multiple-location "display modes" as locations were added/removed (e.g., when a shared library is loaded), they'd always be in multi-location display mode. And we'd get rid of the "breakpoint has a single location that is disabled" special case. Now, after using this for a while, I came to wish that the output would give a better visual clue on each group of "breakpoint + its locations". This commit implements that by simply indenting the location number by one space, like so: (top-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y internal_error 1.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 2 breakpoint keep y -qualified internal_error 2.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3 breakpoint keep y errors.c:54 3.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 3.2 y 0x00007ffff6d50410 in PyErr_SetObject at /usr/src/debug/python2-2.7.15-4.fc27.x86_64/Python/errors.c:54 The need for grouping is clearer if you have breakpoints with dozens of locations, such as when you do "b main" when debugging GDB. Another interesting case where this commit helps is when the user sets a breakpoint by line number, and the line corresponds to a comment or empty line, or to code that was optimized away. E.g., again when debugging GDB: (top-gdb) b 27 Breakpoint 4 at 0x469aa6: file src/gdb/gdb.c, line 28. Note I asked for line 27 but got line 28. "info breakpoints" currently says: (top-gdb) info breakpoints 4 Num Type Disp Enb Address What 4 breakpoint keep y 0x0000000000469aa6 in main(int, char**) at src/gdb/gdb.c:28 Again here we lost the info about the original location spec, line 27. While after this commit, we get: (top-gdb) info breakpoints 4 Num Type Disp Enb Address What 4 breakpoint keep y src/gdb/gdb.c:27 4.1 y 0x0000000000469aa6 in main(int, char**) at src/gdb/gdb.c:28 Lancelot is working on a GDB change that will make GDB slide each breakpoint location's line independently, so we could end up with something like this, even: (top-gdb) info breakpoints 4 Num Type Disp Enb Address What 4 breakpoint keep y func.cc:27 4.1 y 0x0000000000469aa6 in func<float>(float) at func.cc:28 4.2 y 0x000000000047abb8 in func<int>(int) at func.cc:30 The output for watchpoints and catchpoints is unmodified, they will continue being printed like before, as we never print locations for those: Num Type Disp Enb Address What 2 catchpoint keep y syscall "<any syscall>" 3 hw watchpoint keep y *main Before this commit can go in, I'll need to address testsuite fallout, of course. I expect this will be a significant effort, so I'm hoping we can come to agreement on whether the GDB change is OK before wasting time adjusting the testsuite. Documentation adjustments included. They also clean up a few tangent things in the area of the docs I was adjusting to better match reality. Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
2022-05-23Tweak the std::hash<> specialization for aarch64_features.John Baldwin1-12/+15
Move the specialization into an explicit std namespace to workaround a bug in older compilers. GCC 6.4.1 at least fails to compile the previous version with the following error: gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive] struct std::hash<aarch64_features>
2022-05-23Fix loongarch_iterate_over_regset_sections for non-native targets.John Baldwin1-2/+12
Define a constant for the number of registers stored in a register set and use this with register_size to compute the size of the general-purpose register set in core dumps. This also fixes the build on hosts such as FreeBSD that do not define an elf_gregset_t type.
2022-05-23gdb: LoongArch: Implement the iterate_over_regset_sections gdbarch methodTiezhu Yang1-0/+16
When execute the following command on LoongArch: make check-gdb TESTS="gdb.base/auxv.exp" there exist the following unsupported and failed testcases: UNSUPPORTED: gdb.base/auxv.exp: gcore FAIL: gdb.base/auxv.exp: load core file for info auxv on native core dump FAIL: gdb.base/auxv.exp: info auxv on native core dump FAIL: gdb.base/auxv.exp: matching auxv data from live and core UNSUPPORTED: gdb.base/auxv.exp: info auxv on gcore-created dump UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and gcore we can see the following messages in gdb/testsuite/gdb.log: gcore /home/loongson/build.git/gdb/testsuite/outputs/gdb.base/auxv/auxv.gcore Target does not support core file generation. (gdb) UNSUPPORTED: gdb.base/auxv.exp: gcore In order to fix the above issues, implement the iterate_over_regset_sections gdbarch method to iterate over core file register note sections on LoongArch. By the way, with this patch, the failed testcases in gdb.base/corefile.exp and gdb.base/gcore.exp can also be fixed. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-05-23[gdb/testsuite] Fix -prompt handling in gdb_testTom de Vries1-1/+1
With check-read1 I run into: ... [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads^M (gdb) FAIL: gdb.base/ui-redirect.exp: debugging: continue [infrun] fetch_inferior_event: exit^M ... The problem is that proc gdb_test doesn't pass down the -prompt option to proc gdb_test_multiple, due to a typo making this lappend without effect: ... set opts {} lappend "-prompt $prompt" ... Fix this by actually appending to opts. Tested on x86_64-linux.
2022-05-23[gdbsupport] Fix UB in print-utils.cc:int_stringTom de Vries1-1/+5
When building gdb with -fsanitize=undefined, I run into: ... (gdb) PASS: gdb.ada/access_to_packed_array.exp: set logging enabled on maint print symbols^M print-utils.cc:281:29:runtime error: negation of -9223372036854775808 cannot \ be represented in type 'long int'; cast to an unsigned type to negate this \ value to itself (gdb) FAIL: gdb.ada/access_to_packed_array.exp: maint print symbols ... By running in a debug session, we find that this happens during printing of: ... typedef system.storage_elements.storage_offset: \ range -9223372036854775808 .. 9223372036854775807; ... Possibly, an ada test-case could be created that exercises this in isolation. The problem is here in int_string, where we negate a val with type LONGEST: ... return decimal2str ("-", -val, width); ... Fix this by, as recommend, using "-(ULONGEST)val" instead. Tested on x86_64-linux.
2022-05-23[gdb/exp] Fix UB in scalar_binopTom de Vries2-1/+6
When building gdb with -fsanitize=undefined, I run into: ... $ gdb -q -batch -ex "p -(-0x7fffffffffffffff - 1)" src/gdb/valarith.c:1385:10: runtime error: signed integer overflow: \ 0 - -9223372036854775808 cannot be represented in type 'long int' $1 = -9223372036854775808 ... Fix this by performing the substraction in scalar_binop using unsigned types. Tested on x86_64-linux.
2022-05-23[gdb/ada] Fix gdb.ada/dynamic-iface.exp with gcc 7Tom de Vries1-1/+2
This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8: ... (gdb) print obj^M $1 = (n => 3, a => "ABC", value => 93)^M (gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface ... but fails with gcc 7: ... (gdb) print obj^M $1 = ()^M (gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface ... More concretely, we have trouble finding the type of obj. With gcc 8: ... $ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj" ... type = <ref> new concrete.intermediate with record value: integer; end record ... and with gcc 7: ... type = <ref> tagged record null; end record ... The translation from tagged type to "full view" type happens in ada_tag_value_at_base_address, where we hit this code: ... /* Storage_Offset'Last is used to indicate that a dynamic offset to top is used. In this situation the offset is stored just after the tag, in the object itself. */ if (offset_to_top == last) { struct value *tem = value_addr (tag); tem = value_ptradd (tem, 1); tem = value_cast (ptr_type, tem); offset_to_top = value_as_long (value_ind (tem)); } ... resulting in an offset_to_top for gcc 8: ... (gdb) p offset_to_top $1 = -16 ... and for gcc 7: ... (gdb) p offset_to_top $1 = 16 ... The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple changes]") which mentions this change. There's some code right after the code quoted above that deals with this change: ... else if (offset_to_top > 0) { /* OFFSET_TO_TOP used to be a positive value to be subtracted from the base address. This was however incompatible with C++ dispatch table: C++ uses a *negative* value to *add* to the base address. Ada's convention has therefore been changed in GNAT 19.0w 20171023: since then, C++ and Ada use the same convention. Here, we support both cases by checking the sign of OFFSET_TO_TOP. */ offset_to_top = -offset_to_top; } ... but it's not activated because of the 'else'. Fix this by removing the 'else'. Tested on x86_64-linux, with gcc 7.5.0. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057
2022-05-23ld: use definitions in generate_reloc rather than raw literalsMark Harmstone2-7/+24
2022-05-23[gdb/testsuite] Skip language auto in gdb.base/parse_number.expTom de Vries1-0/+5
In test-case gdb.base/parse_number.exp, we skip architecture auto in the $supported_archs loop, to prevent duplicate testing. Likewise, skip language auto and its alias local in the $::all_languages loop. This reduces the number of tests from 17744 to 15572. Tested on x86_64-linux, with a build with --enable-targets=all.
2022-05-23Automatic date update in version.inGDB Administrator1-1/+1
2022-05-22Accept functions with DW_AT_linkage_name presentAlok Kumar Sharma3-1/+115
Currently GDB is not able to debug (Binary generated with Clang) variables present in shared/private clause of OpenMP Task construct. Please note that LLVM debugger LLDB is able to debug. In case of OpenMP, compilers generate artificial functions which are not present in actual program. This is done to apply parallelism to block of code. For non-artifical functions, DW_AT_name attribute should contains the name exactly as present in actual program. (Ref# http://wiki.dwarfstd.org/index.php?title=Best_Practices) Since artificial functions are not present in actual program they not having DW_AT_name and having DW_AT_linkage_name instead should be fine. Currently GDB is invalidating any function not havnig DW_AT_name which is why it is not able to debug OpenMP (Clang). It should be fair to fallback to check DW_AT_linkage_name in case DW_AT_name is absent.
2022-05-22Automatic date update in version.inGDB Administrator1-1/+1
2022-05-21Automatic date update in version.inGDB Administrator1-1/+1
2022-05-20Rename base_breakpoint -> code_breakpointPedro Alves9-57/+57
Even after the previous patches reworking the inheritance of several breakpoint types, the present breakpoint hierarchy looks a bit surprising, as we have "breakpoint" as the superclass, and then "base_breakpoint" inherits from "breakpoint". Like so, simplified: breakpoint base_breakpoint ordinary_breakpoint internal_breakpoint momentary_breakpoint ada_catchpoint exception_catchpoint tracepoint watchpoint catchpoint exec_catchpoint ... The surprising part to me is having "base_breakpoint" being a subclass of "breakpoint". I'm just refering to naming here -- I mean, you'd expect that it would be the top level baseclass that would be called "base". Just flipping the names of breakpoint and base_breakpoint around wouldn't be super great for us, IMO, given we think of every type of *point as a breakpoint at the user visible level. E.g., "info breakpoints" shows watchpoints, tracepoints, etc. So it makes to call the top level class breakpoint. Instead, I propose renaming base_breakpoint to code_breakpoint. The previous patches made sure that all code breakpoints inherit from base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts nicely with a watchpoint also being typically known as a "data breakpoint". After this commit, the resulting hierarchy looks like: breakpoint code_breakpoint ordinary_breakpoint internal_breakpoint momentary_breakpoint ada_catchpoint exception_catchpoint tracepoint watchpoint catchpoint exec_catchpoint ... ... which makes a lot more sense to me. I've left this patch as last in the series in case people want to bikeshed on the naming. "code" has a nice property that it's exactly as many letters as "base", so this patch didn't require any reindentation. :-) Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
2022-05-20Test "set multiple-symbols on" creating multiple breakpointsPedro Alves1-25/+75
To look for code paths that lead to create_breakpoints_sal creating multiple breakpoints, I ran the whole testsuite with this hack: --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -8377,8 +8377,7 @@ create_breakpoints_sal (struct gdbarch *gdbarch, int from_tty, int enabled, int internal, unsigned flags) { - if (canonical->pre_expanded) - gdb_assert (canonical->lsals.size () == 1); + gdb_assert (canonical->lsals.size () == 1); surprisingly, the assert never failed... The way to get to create_breakpoints_sal with multiple lsals is to use "set multiple-symbols ask" and then select multiple options from the menu, like so: (gdb) set multiple-symbols ask (gdb) b overload1arg [0] cancel [1] all [2] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg() [3] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(char) [4] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(double) [5] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(float) [6] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(int) [7] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(long) [8] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(short) [9] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(signed char) [10] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned char) [11] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned int) [12] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned long) [13] /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc:foo::overload1arg(unsigned short) > 2-3 Breakpoint 2 at 0x1532: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 107. Breakpoint 3 at 0x154b: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.cp/ovldbreak.cc, line 110. warning: Multiple breakpoints were set. Use the "delete" command to delete unwanted breakpoints. ... which would trigger the assert. This commit makes gdb.cp/ovldbreak.exp test this scenario. It does that by making set_bp_overloaded take a list of expected created breakpoints rather than just one breakpoint. It converts the procedure to use gdb_test_multiple instead of send_gdb/gdb_expect along the way. Change-Id: Id87d1e08feb6670440d926f5344e5081f5e37c8e
2022-05-20Make sure momentary breakpoints are always thread-specificPedro Alves1-37/+46
This adds a new ctor to momentary_breakpoints with a few parameters that are always necessary for momentary breakpoints. In particular, I noticed that set_std_terminate_breakpoint doesn't make the breakpoint be thread specific, which looks like a bug to me. The point of that breakpoint is to intercept std::terminate calls that happen as result of the called thread throwing an exception that won't be caught by the dummy frame. If some other thread calls std::terminate, IMO, it's no different from some other thread calling exit/_exit, for example. Change-Id: Ifc5ff4a6d6e58b8c4854d00b86725382d38a1a02
2022-05-20Momentary breakpoints should have no breakpoint numberPedro Alves1-1/+0
Momentary breakpoints have no breakpoint number, their breakpoint number should be always 0, to avoid constantly incrementing (or decrementing) the internal breakpoint count. Indeed, set_momentary_breakpoint installs the created breakpoint without a number. However, momentary_breakpoint_from_master incorrectly gives an internal breakpoint number to the new breakpoint. This commit fixes that. Change-Id: Iedcae5432cdf232db9e9a6e1a646d358abd34f95
2022-05-20Add/tweak intro comments of struct breakpoint and several subclassesPedro Alves2-8/+17
This tweaks the intro comments of the following classes: internal_breakpoint momentary_breakpoint breakpoint base_breakpoint watchpoint catchpoint Change-Id: If6b31f51ebbb81705fbe5b8435f60ab2c88a98c8
2022-05-20Move add_location(sal) to base_breakpointPedro Alves5-37/+31
After the previous patches, only base_breakpoint subclasses use add_location(sal), so we can move it to base_breakpoint (a.k.a. base class for code breakpoints). This requires a few casts here and there, but always at spots where you can see from context what the breakpoint's type actually is. I inlined new_single_step_breakpoint into its only caller exactly for this reason. I did try to propagate more use of base_breakpoint to avoid casts, but that turned out unwieldy for this patch. Change-Id: I49d959322b0fdce5a88a216bb44730fc5dd7c6f8
2022-05-20Move common bits of catchpoint/exception_catchpoint to breakpoint's ctorPedro Alves3-19/+21
Move common bits of catchpoint and exception_catchpoint to breakpoint's ctor, to avoid duplicating code. Change-Id: I3a115180f4d496426522f1d89a3875026aea3cf2
2022-05-20Make catchpoint inherit breakpoint, eliminate init_raw_breakpointPedro Alves3-37/+7
struct catchpoint's ctor currently calls init_raw_breakpoint, which is a bit weird, as that ctor-like function takes a sal argument, but catchpoints don't have code locations. Instead, make struct catchpoint's ctor add the catchpoint's dummy location using add_dummy_location. init_raw_breakpoint uses add_location under the hood, and with a dummy sal it would ultimately use the breakpoint's gdbarch for the location's gdbarch, so replace the references to loc->gdbarch (which is now NULL) in syscall_catchpoint to references to the catchpoint's gdbarch. struct catchpoint's ctor was the last user of init_raw_breakpoint, so this commit eliminates the latter. Since catchpoint locations aren't code locations, make struct catchpoint inherit struct breakpoint instead of base_breakpoint. This let's us delete the tracepoint::re_set override too. Change-Id: Ib428bf71efb09fdaf399c56e4372b0f41d9c5869
2022-05-20Make breakpoint_address_bits look at the location kindPedro Alves2-37/+23
Software watchpoints allocate a special dummy location using software_watchpoint_add_no_memory_location, and then breakpoint_address_bits checks whether the location is that special location to decide whether the location has a meaninful address to print. Introduce a new bp_loc_software_watchpoint location kind, and make breakpoint_address_bits use bl_address_is_meaningful instead, which returns false for bp_loc_other, which is in accordance with we document for bp_location::address: /* (... snip ...) Valid for all types except bp_loc_other. */ CORE_ADDR address = 0; Rename software_watchpoint_add_no_memory_location to add_dummy_location, and simplify it. This will be used by catchpoints too in a following patch. Note that neither "info breakpoints" nor "maint info breakpoints" actually prints the addresses of watchpoints, but I think it would be useful to do so in "maint info breakpoints". This approach let's us implement that in the future. Change-Id: I50e398f66ef618c31ffa662da755eaba6295aed7
2022-05-20Make exception_catchpoint inherit base_breakpoint instead of catchpointPedro Alves1-6/+12
exception_catchpoint is really a code breakpoint, with locations set by sals, re-set like other code breakpoints, etc., so make it inherit base_breakpoint. This adds a bit of duplicated code to exception_catchpoint's ctor (copied from struct catchpoint's ctor), but it will be eliminated in a following patch. Change-Id: I9fbb2927491120e9744a4f5e5cb5e6870ca07009
2022-05-20Refactor momentary breakpoints, eliminate set_raw_breakpoint{,_without_location}Pedro Alves1-73/+24
This commit makes set_momentary_breakpoint allocate the breakpoint type without relying on set_raw_breakpoint, and similarly, momentary_breakpoint_from_master not rely on set_raw_breakpoint_without_location. This will let us convert init_raw_breakpoint to a ctor in a following patch. The comment about set_raw_breakpoint being used in gdbtk sources is stale. gdbtk no longer uses it. Change-Id: Ibbf77731e4b22e18ccebc1b5799bbec0aff28c8a
2022-05-20Refactor set_internal_breakpoint / internal_breakpoint ctorPedro Alves1-19/+18
This moves initialization of internal_breakpoint's breakpoint fields to internal_breakpoint's ctor, and stops using new_breakpoint_from_type for internal_breakpoint breakpoints. Change-Id: I898ed0565f47cb00e4429f1c6446e6f9a385a78d
2022-05-20Convert init_ada_exception_catchpoint to a ctorPedro Alves3-59/+49
Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I presume so it can call the static describe_other_breakpoints function. I think this is a dependency inversion. init_ada_exception_catchpoint, being code specific to Ada catchpoints, should be in ada-lang.c, and describe_other_breakpoints, a core function, should be exported. And then, we can convert init_ada_exception_catchpoint to an ada_catchpoint ctor. Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1
2022-05-20Make ada_catchpoint_location's owner ctor parameter be ada_catchpointPedro Alves1-16/+16
This commit changes ada_catchpoint_location's ctor from: ada_catchpoint_location (breakpoint *owner) to: ada_catchpoint_location (ada_catchpoint *owner) just to make the code better document intention. To do this, we need to move the ada_catchpoint_location type's definition to after ada_catchpoint is defined, otherwise the compiler doesn't know that ada_catchpoint is convertible to struct breakpoint. Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d
2022-05-20init_breakpoint_sal -> base_breakpoint::base_breakpointPedro Alves2-122/+129
This converts init_breakpoint_sal to a base_breakpoint constructor. It removes a use of init_raw_breakpoint. To avoid manually adding a bunch of parameters to new_breakpoint_from_type, and manually passing them down to the constructors of a number of different base_breakpoint subclasses, make new_breakpoint_from_type a variable template function. Change-Id: I4cc24133ac4c292f547289ec782fc78e5bbe2510
2022-05-20Remove "internal" parameter from a couple functionsPedro Alves1-3/+3
None of init_breakpoint_sal, create_breakpoint_sal, and strace_marker_create_breakpoints_sal make use of their "internal" parameter, so remove it. Change-Id: I943f3bb44717ade7a7b7547edf8f3ff3c37da435
2022-05-20More breakpoint_ops parameter eliminationPedro Alves2-11/+8
Remove breakpoint_ops parameters from a few functions that don't need it. Change-Id: Ifcf5e1cc688184acbf5e19b8ea60138ebe63cf28
2022-05-20Make a few functions work with base_breakpoint instead of breakpointPedro Alves2-31/+8
This makes tracepoints inherit from base_breakpoint, since their locations are code locations. If we do that, then we can eliminate tracepoint::re_set and tracepoint::decode_location, as they are doing the same as the base_breakpoint implementations. With this, all breakpoint types created by new_breakpoint_from_type are code breakpoints, i.e., base_breakpoint subclasses, and thus we can make it return a base_breakpoint pointer. Finally, init_breakpoint_sal can take a base_breakpoint pointer as "self" pointer too. This will let us convert this function to a base_breakpoint ctor in a following patch. Change-Id: I3a4073ff1a4c865f525588095c18dc42b744cb54
2022-05-20ranged_breakpoint: move initialization to ctorPedro Alves1-8/+19
Move initialization of ranged_breakpoint's fields to its ctor. Change-Id: If7b842861f3cc6a429ea329d45598b5852283ba3
2022-05-20ranged_breakpoint: use install_breakpointPedro Alves1-12/+5
This commit replaces a chunk of code in break_range_command by an equivalent call to install_breakpoint. Change-Id: I31c06cabd36f5be91740aab029265f678aa78e35
2022-05-20ranged_breakpoint: don't use init_raw_breakpointPedro Alves1-1/+1
ranged_breakpoint's ctor already sets the breakpoint's type to bp_hardware_breakpoint. Since this is a "regular" breakpoint, b->pspace should remain NULL. Thus, the only thing init_raw_breakpoint is needed for, is to add the breakpoint's location. Do that directly. Change-Id: I1505de94c3919881c2b300437e2c0da9b05f76bd
2022-05-20Make structs breakpoint/base_breakpoint/catchpoint be abstractPedro Alves2-1/+20
You should never instanciate these types directly. Change-Id: I8086c74c415eadbd44924bb0ef20f34b5b97ee6f
2022-05-20add_location_to_breakpoint -> breakpoint::add_locationPedro Alves2-37/+36
Make add_location_to_breakpoint be a method of struct breakpoint. A patch later in the series will move this to base_breakpoint, but for now, it needs to be here. Change-Id: I5bdc2ec1a7c2d66f26f51bf6f6adc8384a90b129
2022-05-20PowerPC: Make test gdb.arch/powerpc-power10.exp Endian independent.Carl Love1-368/+746
The .quad statement stores the 64-bit hex value in Endian order. When used to store a 64-bit prefix instructions on Big Endian (BE) systems, the .quad statement stores the 32-bit suffix followed by the 32-bit prefix rather than the expected order of prefix word followed by the suffix word. GDB fetches 32-bits at a time when disassembling instructions. The disassembly on BE gets messed up since GDB fetches the suffix first and interprets it as a word instruction not a prefixed instruction. When gdb fetches the prefix part of the instruction, following the initial suffix word, gdb associates the prefix word incorrectly with the following 32-bits as the suffix for the instruction when in fact it is the following instruction. For example on BE we have two prefixed instructions stored using the .quad statement as follows: addr word GDB action --------------------------------------------- 1 suffix inst A <- GDB interprets as a word instruction 2 prefix inst A <- GDB uses this prefix with 3 suffix inst B <- this suffix rather than the suffix at addr 1. 4 prefix inst B This patch changes the .quad statement into two .longs to explicitly store the prefix followed by the suffix of the instruction. The patch rearranges the instructions to put all of the word instructions together followed by the prefix instructions for clarity. The patch has been tested on Power 10 and Power 7 BE and LE to verify the change works as expected.
2022-05-20Remove obsolete text from documentationTom Tromey1-3/+0
The documentation says that -enable-pretty-printing is experimental in 7.0 and may change -- that's long enough ago that I think we can say that this text is no longer correct or useful.
2022-05-20Stop readekf and objdump from aggressively following links.Nick Clifton8-66/+179
* dwarf.c (dwarf_select_sections_by_names): Return zero if no sections were selected. (dwarf_select_sections_by_letters): Likewise. * dwarf.h: (dwarf_select_sections_by_names): Update prototype. (dwarf_select_sections_by_letters): Update prototype. * objdump.c (might_need_separate_debug_info): New function. (dump_bfd): Call new function before attempting to load separate debug info files. (main): Do not enable dwarf section dumping for -WK or -WN. * readelf.c (parse_args): Do not enable dwarf section dumping for -wK or -wN. (might_need_separate_debug_info): New function. (process_object): Call new function before attempting to load separate debug info files. * testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE debuginfod tests to pass. * testsuite/binutils-all/objdump.Wk: Add extra regexps. * testsuite/binutils-all/readelf.k: Add extra regexps.
2022-05-20RISC-V: Update zfinx implement with zicsr.Jia-Wei Chen3-14/+51
Update zfinx implement with zicsr, fix missing fcsr use by zfinx. add zicsr imply by zfinx. bfd/ChangeLog: * elfxx-riscv.c: New imply. gas/ChangeLog: * testsuite/gas/riscv/csr-insns-pseudo-zfinx.d: New test. opcodes/ChangeLog: * riscv-opc.c: Update insn class.
2022-05-20RISC-V: Remove RV128-only fmv instructionsTsukasa OI5-8/+8
As fmv.x.q and fmv.q.x instructions are RV128-only (not RV64-only), it should be removed until RV128 support for GNU Binutils is required again. gas/ChangeLog: * testsuite/gas/riscv/fmv.x.q-rv64-fail.d: New failure test. * testsuite/gas/riscv/fmv.x.q-rv64-fail.l: Likewise. * testsuite/gas/riscv/fmv.x.q-rv64-fail.s: Likewise. include/ChangeLog: * opcode/riscv-opc.h (MATCH_FMV_X_Q, MASK_FMV_X_Q, MATCH_FMV_Q_X, MASK_FMV_Q_X): Remove RV128-only instructions. opcodes/ChangeLog: * riscv-opc.c (riscv_opcodes): Remove RV128-only instructions.
2022-05-20Fix non-pointer type compilation error in aix-thread.cAditya Vidyadhar Kamath1-2/+2
In aix-thread.c we use ms->value_address () to get the symbol address. This triggers the following compiler error... base operand of '->' has non-pointer type 'bound_minimal_symbol' ... because ms is not a pointer. This commit fixes this error by using ms.value_address () instead.
2022-05-20add a trie to map quickly from address range to compilation unitSteinar H. Gunderson1-19/+367
When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line() becomes a hotspot, as perf wants to get line number information (for inline-detection purposes) for each and every sample. In Chromium in particular (the content_shell binary), this entails going through 475k address ranges, which takes a long time when done repeatedly. Add a radix-256 trie over the address space to quickly map address to compilation unit spaces; for content_shell, which is 1.6 GB when some (but not full) debug information turned is on, we go from 6 ms to 0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x speedup. There is a modest RAM increase of 180 MB in this binary (the existing linked list over ranges uses about 10 MB, and the entire perf job uses between 2–3 GB for a medium-size profile); for smaller binaries with few ranges, there should be hardly any extra RAM usage at all.
2022-05-20Tidy warn-execstack handlingAlan Modra6-22/+17
Make ld and bfd values consistent by swapping values 0 and 2 in link_info.warn_execstack. This has the benefit of making the value an "extended" boolean, with 0 meaning no warning, 1 meaning warn, other values a conditional warning. Yes, this patch introduces fails on arm/aarch64. Not a problem with this patch but an arm/aarch64 before_parse problem. bfd/ * elflink.c (bfd_elf_size_dynamic_sections): Adjust warn_execstack test. include/ * bfdlink.h (warn_execstack): Swap 0 and 2 meaning. ld/ * configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0, 1, 2 consistent with link_info.warn_execstack. * ld.texi: Typo fixes. * lexsup.c (parse_args): Adjust setting of link_info.warn_execstack. (elf_static_list_options): Adjust help message conditions. * configure: Regenerate.
2022-05-20Automatic date update in version.inGDB Administrator1-1/+1
2022-05-19arm: Fix system register fpcxt_ns and fpcxt_s naming convention.Srinath Parvathaneni3-3/+88
The current assembler accepts system registers FPCXTNS and FPCXTS for Armv8.1-M Mainline Instructions VSTR, VLDR, VMRS and VMSR. Assembler should be also allowing FPCXT_NS, fpcxt_ns, fpcxtns, FPCXT_S, fpcxt_s and fpcxts. This patch fixes the issue.
2022-05-19gdb/doc: use @value{GDBP} in 'info pretty-printer' exampleAndrew Burgess1-8/+8
Update the 'info pretty-printer' example in the manual to make use of @value{GDBP} instead of hard-coding '(gdb)'.
generated by cgit v1.1 at 2025-09-27 02:46:57 +0000