aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2022-09-22[gdb/symtab] Add all_comp_units/all_type_units views on all_unitsTom de Vries3-11/+32
Add all_comp_units/all_type_units views on all_units. Having the views allows us to: - easily get the number of CUs or TUs in all_units, and - easily access the nth CU or TU. This minimizes the use of tu_stats.nr_tus. Tested on x86_64-linux.
2022-09-22[gdb/symtab] Rename all_comp_units to all_unitsTom de Vries3-87/+87
Mechanically rename all_comp_units to all_units: ... $ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/* ... Tested on x86_64-linux.
2022-09-22gdb/python: restrict the names accepted by gdb.register_window_typeAndrew Burgess4-1/+105
I noticed that, from Python, I could register a new TUI window that had whitespace in its name, like this: gdb.register_window_type('my window', MyWindowType) however, it is not possible to then use this window in a new TUI layout, e.g.: (gdb) tui new-layout foo my window 1 cmd 1 Unknown window "my" (gdb) tui new-layout foo "my window" 1 cmd 1 Unknown window ""my" (gdb) tui new-layout foo my\ window 1 cmd 1 Unknown window "my\" GDB clearly uses the whitespace to split the incoming command line. I could fix this by trying to add a mechanism by which we can use whitespace within a window name, but it seems like an easier solution if we just forbid whitespace within a window name. Not only is this easier, but I think this is probably the better solution, identifier names with spaces in would mean we'd need to audit all the places a window name could be printed and ensure that the use of a space didn't make the output ambiguous. So, having decided to disallow whitespace, I then thought about other special characters. We currently accept anything as a window name, and I wondered if this was a good idea. My concerns were about how special characters used in a window name might cause confusion, for example, we allow '$' in window names, which is maybe fine now, but what if one day we wanted to allow variable expansion when creating new layouts? Or what about starting a window name with '-'? We already support a '-horizontal' option, what if we want to add more in the future? Or use of the special character '{' which has special meaning within a new layout? In the end I figured it might make sense to place some restrictive rules in place, and then relax the rules later if/when users complain, we can consider each relaxation as its requested. So, I propose that window names should match this regular expression: [a-zA-Z][-_.a-zA-Z0-9]* There is a chance that there is user code in the wild which will break with the addition of this change, but hopefully adapting to the new restrictions shouldn't be too difficult.
2022-09-22gdb/testsuite: Add test to step through function epilogueBruno Larsen2-0/+136
The testsuite implicitly tests GDB's ability to step through epilogues in multiple tests, without doing it explicitly anywhere. This is unfortunate, as clang does not emit epilogue information, so using clang on our testsuite makes many tests fail. This patch adds a central, explicit test for walking through the epilogue so we can safely remove this from other tests and have them working with clang. The test created attempts to step through a simple epilogue, an epilogue that ends on another epilogue, and epilogues leading to other function calls.
2022-09-22gdb.base/skip.exp: Use finish to exit functionsBruno Larsen1-17/+17
gdb.base/skip.exp was making use of a fixed number of step commands to exit some functions. This caused some problems when using clang to test GDB, as GDB would need fewer steps to reach the desired spots. For instance, when testing in the section "step after disabling 3", the log looks like this: Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); (gdb) step bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 21 return 1; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1 step foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 42 return 0; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2 step main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34 34 test_skip_file_and_function (); (gdb) step test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59 59 test_skip (); (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3 step test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48 48 } (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4 step test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60 60 skip1_test_skip_file_and_function (); (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5 This shows that the feature is working but because the inferior lands in a different location, it registers as a failure. Seeing as along with this difference, there are also some differences that depend on gcc versions (where gdb might stop back at line 32 before entering foo), it would not be easy to test for this behavior using steps and analzing where the inferior stops at each point. On the other hand, using gdb_step_until is not feasible because we'd possibly gloss over stepping into baz and rendering the whole test useless. Instead, skip.exp now uses finish to leave functions, synchronizing through compilers and compiler versions. Some test names were also changed to be a bit more descriptive. The new log looks like this, independently of compiler used: Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); (gdb) step bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 21 return 1; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar finish Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); Value returned is $2 = 1 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar step foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 42 return 0; (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo finish Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42 main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32 32 x = baz ((bar (), foo ())); Value returned is $3 = 0 (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo step 34 test_skip_file_and_function (); (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
2022-09-22fix gdb.base/jit-elf.exp when testing with clangBruno Larsen1-1/+1
When using clang as the compiler for the target, gdb.base/jit-elf.exp was failing because the filename displayed when GDB attached to the inferior was only showing up as with a relative path, like so: (gdb) attach 3674146 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146 Reading symbols from /lib64/libm.so.6... Reading symbols from .gnu_debugdata for /lib64/libm.so.6... (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach While gcc's output is as follows: (gdb) attach 3592961 Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961 Reading symbols from /lib64/libm.so.6... Reading symbols from .gnu_debugdata for /lib64/libm.so.6... (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach This difference only happens when GDB's configure is ran using a relative path, but seeing as testing the full path is not important for this specific test, it feels worth fixing anyway. To fix the false positive, the regexp for checking where gdb has stopped was relaxed a little to allow the relative path.
2022-09-22gdb/testsuite: fix gdb.base/msym-bp-shl when running with ClangBruno Larsen1-1/+1
When trying to test gdb.base/msym-bp-shl.exp using clang, it would have many failures because one of the version of the foo function was being optimized away. Adding __attribute__ ((used)) to it fixed this.
2022-09-22gdb/testsuite: fix testing gdb.base/skip-inline.exp with clangBruno Larsen1-45/+62
When testing gdb.base/skip-inline.exp using clang, we get failures when trying to step out of functions, since clang requires one fewer step when compared to gcc. The inferior gets increasingly out of sync as the test continues because of this difference, which generates those failures. This commit fixes this by switching those hardcoded steps to gdb_step_until, to guarantee that the inferior is always synced to what the test expects. This approach does not work for the parts that use step 2 or step 3, so when we identify that clang is being used, those tests are skipped.
2022-09-22Change gdb.base/skip-solib.exp deal with lack of epilogue informationBruno Larsen2-2/+4
When running gdb.base/skip-solib.exp, the backtrace tests could fail with compilers that associated epilogue instructions with the last statement line of the function, instead of associating it with the closing brace, despite the feature being fully functional. As an example, when testing skipping the function square, the testsuite would show Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5 5 return square(0); (gdb) step 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 (gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step bt #0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6 #1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6 #2 0x0000000000401065 in _start () (gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt Which means that the feature is working, the testsuite is just mis-identifying it. To avoid this problem, the skipped function calls have been sent to a line before `return`, so epilogues won't factor in.
2022-09-22gdb/testsuite: Add a proc to test where compiler links the epilogueBruno Larsen1-0/+32
Different compilers link the epilogue of functions to different lines. As an example, gcc links it to the closing brace of the function, whereas clang links it to the last statement of the function. This difference is important for the testsuite, since the where GDB will land after a step can be wildly different. Where possible, this dependency should be side-stepped in the testsuite, but it isn't always possible, so this commit adds a gdb_caching_proc that is able to detect where the epilogue is linked, so tests can react accordingly.
2022-09-21gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and renameSimon Marchi2-108/+4
gdb_bfd.c and remote.c contain identical implementations of a fileio_error -> errno function. Factor that out to gdbsupport/fileio.{h,cc}. Rename it fileio_error_to_host, for symmetry with host_to_fileio_error. Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df
2022-09-21gdbsupport: convert FILEIO_* macros to an enumSimon Marchi10-108/+114
Converting from free-form macros to an enum gives a bit of type-safety. This caught places where we would assign host error numbers to what should contain a target fileio error number, for instance in target_fileio_pread. I added the FILEIO_SUCCESS enumerator, because remote.c:remote_hostio_parse_result initializes the remote_errno output variable to 0. It seems better to have an explicit enumerator than to assign a value for which there is no enumerator. I considered initializing this variable to FILEIO_EUNKNOWN instead, such that if the remote side replies with an error and omits the errno value, we'll get an errno that represents an error instead of 0 (which reprensents no error). But it's not clear what the consequences of that change would be, so I prefer to err on the side of caution and just keep the existing behavior (there is no intended change in behavior with this patch). Note that remote_hostio_parse_resul still reads blindly what the remote side sends as a target errno into this variable, so we can still end up with a nonsensical value here. It's not good, but out of the scope of this patch. Convert host_to_fileio_error and fileio_errno_to_host to return / accept a fileio_error instead of an int, and cascade the change in the whole chain that uses that. Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03
2022-09-21gdbsupport: move include/gdb/fileio.h contents to fileio.hSimon Marchi3-3/+3
I don't see why include/gdb/fileio.h is placed there. It's not installed by "make install", and it's not included by anything outside of gdb/gdbserver/gdbsupport. Move its content back to gdbsupport/fileio.h. I have omitted the bits inside an `#if 0`, since it's obviously not used, as well as the "limits" constants, which are also unused. Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
2022-09-21gdbsupport: change path_join parameter to array_view<const char *>Simon Marchi1-2/+2
When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single character name, we hit this assertion failure: $ ./gdb -q --data-directory=data-directory -nx ./x /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. The backtrace: #3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60 #4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239 #5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203 #6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84 #7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122 #8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471 #9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513 #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209 #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319 #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344 #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32 The problem is this line in path_join: gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path)); ... where `path` is "x". IS_ABSOLUTE_PATH eventually calls HAS_DRIVE_SPEC_1: #define HAS_DRIVE_SPEC_1(dos_based, f) \ ((f)[0] && ((f)[1] == ':') && (dos_based)) This macro accesses indices 0 and 1 of the input string. However, `f` is a string_view of length 1, so it's incorrect to try to access index 1. We know that the string_view's underlying object is a null-terminated string, so in practice there's no harm. But as far as the string_view is concerned, index 1 is considered out of bounds. This patch makes the easy fix, that is to change the path_join parameter from a vector of to a vector of `const char *`. Another solution would be to introduce a non-standard gdb::cstring_view class, which would be a view over a null-terminated string. With that class, it would be correct to access index 1, it would yield the NUL character. If there is interest in having this class (it has been mentioned a few times in the past) I can do it and use it here. This was found by running tests such as gdb.ada/arrayidx.exp, which produce 1-char long filenames, so adding a new test is not necessary. Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi150-1323/+1320
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi14-116/+119
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi97-687/+683
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-09-21gdb: add type::target_type / type::set_target_typeSimon Marchi10-61/+70
Add the `target_type` and `set_target_type` methods on `struct type`, in order to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
2022-09-20Make stdin_event_handler staticTom Tromey2-2/+1
I noticed that stdin_event_handler is only used in event-top.c, so this patch changes it to be 'static'.
2022-09-20Constify some target_so_ops instancesTom Tromey13-88/+112
This changes some target_so_ops instances to be const. This makes their use a little more obvious (they can't be mutated) and also allows for the removal of some initialization code.
2022-09-20Move solib_ops into gdbarchTom Tromey17-52/+59
This changs solib_ops to be an ordinary gdbarch value and updates all the uses. This removes a longstanding FIXME and makes the code somewhat cleaner as well.
2022-09-20Remove current_target_so_opsTom Tromey3-14/+3
current_target_so_ops is only set in a single place. It seems better to simply remove it.
2022-09-20gdb/testsuite: add a debuginfod-support.exp helper libraryAndrew Burgess2-111/+243
We currently have a single test for GDB's debuginfod support, this is gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the setup, starts debuginfod, and then does the testing. This commit tries to split the existing script in two, there is a new library lib/debuginfod-support.exp, which contains a helper functions related to running debuginfod tests. All the code in the new library is basically copied from the existing test case (which is why I retained the copyright date range on the new library), with some minor adjustments to try and make the code a little more generic. One change I made, for example, is the library offers functions to shut down debuginfod, previously we just relied on expect shutting down debuginfod when dejagnu completed. The existing test script is updated to make use of the new library code, and this test is still passing for me. The only change in the test results is a single test where I changed the name to remove the port number from the test name - the port number can change from run to run, so could make it hard to compare test results. I have also done a little light house keeping on the original test script, updating and adding new comments, and making use of proc_with_prefix in a couple of places.
2022-09-19gdb: add ATTRIBUTE_PRINTF to gdb_bfd_error_handlerEnze Li1-1/+1
I see this error when building with clang, CXX gdb_bfd.o gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral] const std::string str = string_vprintf (fmt, ap_copy); ^~~ 1 error generated. This patch adds missing ATTRIBUTE_PRINTF to fix the error. Tested on x86_64-linux with gcc 12 and clang 14.
2022-09-17[gdb/symtab] Fix "file index out of range" complaintTom de Vries3-10/+59
With the test-case included in this commit, we run into this FAIL: ... (gdb) p var^M During symbol reading: file index out of range^M $1 = 0^M (gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints ... This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), which contains this change in read_file_scope: ... - handle_DW_AT_stmt_list (die, cu, fnd, lowpc); + if (lowpc != highpc) + handle_DW_AT_stmt_list (die, cu, fnd, lowpc); ... The change intends to avoid a problem with a check in lnp_state_machine::check_line_address, but also prevents the file and dir tables from being read, which causes the complaint. Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the call to dwarf_decode_lines in handle_DW_AT_stmt_list. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561
2022-09-16BFD error message suppression test caseKevin Buettner2-0/+229
This commit adds a GDB test case which tests GDB's BFD error handler hook for suppressing output of all but the first identical messages. See the comment at the beginning of bfd-errors.exp for details about this new test. I've tested this test for both 32- and 64-bit ELF files and also on both little endian and big endian machines. It also works for both native and remote targets. The only major restriction is that it only works for ELF targets.
2022-09-16Suppress printing of superfluous BFD error messagesKevin Buettner1-0/+67
This commit adds a hook to the BFD error handler for suppressing identical messages which have been output once already. It's motivated by this Fedora bug... https://bugzilla.redhat.com/show_bug.cgi?id=2083315 ...in which over 900,000 BFD error messages are output when attaching to firefox. From the bug report, the messages all say: BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38) Since there's no (additional) context which might assist the user in determining what's wrong, there's really no point in outputting more than one message. Of course, if BFD should output some other/different message, it should be output too, but all future messages identical to those already output should be suppressed. For the firefox problem, it turned out that there were only 37 sections, but something was referring to section #38. I haven't investigated further to find out how this came to be. Despite this problem, useful debugging might still be done, especially if the user doesn't care about debugging the problematic library. If it turns out that knowing the quantity of messages might be useful, I've implemented the suppression mechanism by keeping a count of each identical message. A new GDB command, perhaps a 'maintenance' command, could be added to print out each message along with the count. I haven't implemented this though because I'm not convinced of its utility. Also, the BFD message printer has support for BFD- specific format specifiers. The BFD message strings that GDB stores in its map are sufficient for distinguishing messages from each other, but are not identical to those output by BFD's default error handler. So, that problem would need to be solved too.
2022-09-16[gdb/symtab] Handle named DW_TAG_unspecified_type DIETom de Vries3-0/+69
With the test-case included in the patch, we run into: ... (gdb) info types -q std::nullptr_t^M During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M ^M File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M 2198: typedef decltype(nullptr) std::nullptr_t;^M (gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \ without complaint ... Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify in the test-case using "maint print symbols" that the symbol exists. Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271
2022-09-16[gdb/tdep] Fix PowerPC IEEE 128-bit format arg passingTom de Vries3-6/+49
On a powerpc system with gcc 12 built to default to 128-bit IEEE long double, I run into: ... (gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M $8 = 0 + 0i^M (gdb) FAIL: gdb.base/varargs.exp: print \ find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4) ... This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param. Fix this and similar cases, and expand the test-case to test handling of homogeneous aggregates. Tested on ppc64le-linux, power 10. Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com> Tested-by: Carl Love <cel@us.ibm.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543
2022-09-16[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64Tom de Vries1-5/+12
[ Another attempt at fixing the problem described in commit cd919f5533c ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ] When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with aarch64-linux, we run into: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \ tmp-dw2-dir-file-name.c:999^M (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The breakpoint set at compdir_missing__ldir_missing__file_basename_label, address 0x400608 starts at a line entry: ... CU: tmp-dw2-dir-file-name.c: File name Line number Starting address View Stmt tmp-dw2-dir-file-name.c 999 0x400608 x tmp-dw2-dir-file-name.c 1000 0x40062c x tmp-dw2-dir-file-name.c - 0x40062c ... and therefore the breakpoint is printed without instruction address. In contrast, for x86_64-linux, we have the breakpoint printed with instruction address: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \ at tmp-dw2-dir-file-name.c:999^M (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The breakpoint set at compdir_missing__ldir_missing__file_basename_label, address 0x004004c1 doesn't start at a line entry: ... CU: tmp-dw2-dir-file-name.c: File name Line number Starting address View Stmt tmp-dw2-dir-file-name.c 999 0x4004bd x tmp-dw2-dir-file-name.c 1000 0x4004d3 x tmp-dw2-dir-file-name.c - 0x4004d3 ... Fix this by: - unifying behaviour between the archs by adding an explicit line number entry for the address compdir_missing__ldir_missing__file_basename_label, making the FAIL reproducible on x86_64-linux. - expecting the breakpoint to be printed without instruction address. Tested on x86_64-linux and aarch64-linux.
2022-09-16[gdb] Handle pending ^C after rl_callback_read_charTom de Vries1-0/+16
In completion tests in various test-cases, we've been running into these "clearing input line" timeouts: ... (gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd" FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout) ... where $cmd == "maintenance selftest name_that_does_not_exist". AFAIU, the following scenario happens: - expect sends "$cmd\t" - gdb detects the stdin event, and calls rl_callback_read_char until it comes to handle \t - readline interprets the \t as completion, tries to complete, fails to do so, outputs a bell (^G) - expect sees the bell, and proceeds to send ^C - readline is still in the call to rl_callback_read_char, and stores the signal in _rl_caught_signal - readline returns from the call to rl_callback_read_char, without having handled _rl_caught_signal - gdb goes to wait for the next event - expect times out waiting for "Quit", the expected reaction for ^C Fix this by handling pending signals after each call to rl_callback_read_char. The fix is only available for readline 8.x, if --with-system-readline provides an older version, then the fix is disabled due to missing function rl_check_signals. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813
2022-09-13gdb/testsuite: Update gdb.base/so-impl-ld.expBruno Larsen2-13/+5
gdb.base/so-impl-ld.exp was setup assuming that the compiler would add epilogue information and that GDB would stop in the } line. This would make clang tests fail like so: step^M solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M 7|__ return arg*arg;|__|___/* HERE */^M (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call next^M main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M 22|_ return 0;^M (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call next^M 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call This patch changes it so solib_main has 2 lines where GDB can stop regardless of compiler choices, and updates the exp file to generically deal with unknown number of steps until leaving that function.
2022-09-13gdb/testsuite: introduce gdb_step_untilBruno Larsen1-0/+30
Currently, GDB's testsuite uses a set amount of step commands to exit functions. This is a problem if a compiler emits different epilogue information from gcc, or emits no epilogue information at all. It was most noticeable if Clang was used to test GDB. To fix this unreliability, this commit introduces a new proc that will step the inferior until it is stopped at a line that matches the given regexp, or until it steps too many times - defined as an optional argument. If the line is found, it shows up as a single PASS in the test, and if the line is not found, a single FAIL is emitted. This patch only introduces this proc, but does not add it to any existing tests, these will be introduced in the following commit.
2022-09-13explicitly test for stderr in gdb.base/dprintf.expBruno Larsen1-0/+10
Not all compilers add stderr debug information when compiling a program. Clang, for instance, prefers to add nothing from standard libraries and let an external debug package have this information. Because of this, gdb.base/dprintf.exp was failing when GDB attempted to use dprintf as a call to fprintf(stderrr, ...), like this: (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call continue Continuing. kickoff 1234 also to stderr 1234 'stderr' has unknown type; cast it to its declared type (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout) To avoid this false positive, we explicitly test to see if the compiler has added information about stderr at all, and abort testing dprintf as an fprintf call if it is unavailable.
2022-09-13gdb/csky rm csky_print_registers_infoJiangshuai Li1-25/+0
The reason for implementing this interface is that we want to print GPR, PC, EPC, PSR and EPSR when the "info register" command is executed. A prev patch has added PC, EPC, PSR and EPSR to reggroup general_group, the purpose has been achieved, so this function is no longer required.
2022-09-13gdb/csky rm csky_memory_insert/remove_breakpointJiangshuai Li1-201/+0
Software breakpoints are inserted or removed by the gdb stub via remote protocol, these two functions are no longer needed.
2022-09-13gdb/csky add unwinder for long branch casesJiangshuai Li2-5/+60
There are two sequences of instructions for long branch: 1. jmpi [pc+4] //insn code: 0xeac00001 .long addr 2. lrw t1, [pc+8] //insn code: 0xea8d0002 jmp t1 //insn code: 0x7834 nop //insn code: 0x6c03 .long addr
2022-09-13gdbserver/csky add csky gdbserver supportJiangshuai Li4-0/+198
Add new files: gdb/arch/csky.c gdb/arch/csky.h gdb/features/cskyv2-linux.c gdbserver/linux-csky-low.cc 1. In gdb/arch/csky.c file, add function "csky_create_target_description()" for csky_target::low_arch_setup(). later, it can be used for csky native gdb. 2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include gprs, pc, hi, lo, float, vector and float control registers. 3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to get/set registers. The main data structures in asm/ptrace.h are: struct pt_regs { unsigned long tls; unsigned long lr; unsigned long pc; unsigned long sr; unsigned long usp; /* * a0, a1, a2, a3: * r0, r1, r2, r3 */ unsigned long orig_a0; unsigned long a0; unsigned long a1; unsigned long a2; unsigned long a3; /* * r4 ~ r13 */ unsigned long regs[10]; /* r16 ~ r30 */ unsigned long exregs[15]; unsigned long rhi; unsigned long rlo; unsigned long dcsr; }; struct user_fp { unsigned long vr[96]; unsigned long fcr; unsigned long fesr; unsigned long fid; unsigned long reserved; };
2022-09-12Use checked_static_cast in more placesTom Tromey7-22/+14
I went through all the uses of dynamic_cast<> in gdb, looking for ones that could be replaced with checked_static_cast. This patch is the result. Regression tested on x86-64 Fedora 34.
2022-09-12add xfails to gdb.base/complex-parts.exp when testing with clangBruno Larsen1-0/+5
clang doesn't add encoding to the name of complex variables, only says that the type name is complex, making the relevant tests fail. This patch adds the xfails to the tests that expect the variable name to include it.
2022-09-12Fix gdb.base/call-ar-st to work with ClangBruno Larsen1-1/+12
When running gdb.base/call-ar-st.exp against Clang, we see one FAIL, like so: print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274 274 print_int_array(array_i); /* -step1- */ (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays With GCC we instead see: print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274 274 print_int_array(array_i); /* -step1- */ (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays The difference is that with Clang we get: array_i=<main.integer_array>, ... instead of array_i = <integer_array>, ... These symbols are local static variables, and "main" is the name of the function they are defined in. GCC instead appends a sequence number to the linkage name: $ nm -A call-ar-st.gcc | grep integer_ call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968 $ nm -A call-ar-st.clang | grep integer_ call-ar-st:00000000004061a0 b main.integer_array This commit changes the testcase to accept both outputs, as they are functionally identical. Co-Authored-By: Pedro Alves <pedro@palves.net> Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
2022-09-12fix gdb.base/access-mem-running.exp for clang testingBruno Larsen1-1/+1
Clang was optimizing global_var away because it was not being used anywhere. this commit fixes that by adding the attribute used it.
2022-09-12update gdb.base/info-program.exp to not fail with clangBruno Larsen1-3/+3
The test specifically mentions that it doesn't care where the program stops, however it was still testing for a specific location. The clang compiler emits different line information for epilogue, so GDB reports a different stopping location, depending on the used compiler. With this patch the test works even with clang.
2022-09-12gdb/testsuite: change gdb.base/nodebug.exp to not fail with clangBruno Larsen1-2/+10
Clang organizes the variables differently to gcc in the original version of this code, leading to the following differences when testing p (int*) &dataglobal + 1 gcc: $16 = (int *) 0x404034 <datalocal> clang: $16 = (int *) 0x404034 <dataglobal8> However, since the important part of this test doesn't seem to be which symbol is linked, but rather if GDB is correctly increasing the address. This test was changed to actually measure address changes, instead of assuming the ordering and naming of symbols. Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2022-09-12[gdb] Fix abort in selftest run_on_main_thread with ^CTom de Vries1-2/+6
When running selftest run_on_main_thread and pressing ^C, we can run into: ... Running selftest run_on_main_thread. terminate called without an active exception Fatal signal: Aborted ... The selftest function looks like this: ... static void run_tests () { std::thread thread; done = false; { gdb::block_signals blocker; thread = std::thread (set_done); } while (!done && gdb_do_one_event () >= 0) ; /* Actually the test will just hang, but we want to test something. */ SELF_CHECK (done); thread.join (); } ... The error message we see is due to the destructor of thread being called while thread is joinable. This is supposed to be taken care of by thread.join (), but the ^C prevents that one from being called, while the destructor is still called. Fix this by ensuring thread.join () is called (if indeed required) before the destructor using SCOPE_EXIT. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29549
2022-09-12[gdb/symtab] Support .gdb_index section with TUs in .debug_infoTom de Vries3-2/+75
The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support .debug_names section with TUs in .debug_info"). Tested on x86_64-linux.
2022-09-12[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64leTom de Vries2-10/+5
In commit cd919f5533c ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp independent of prologue analyzers, using this change: ... - gdb_breakpoint $func + gdb_breakpoint *$func ... That however caused a regression on ppc64le. For PowerPC, as described in the ELFv2 ABI, a function can have a global and local entry point. Setting a breakpoint on *$func effectively creates a breakpoint for the global entry point, so if the function is entered through the local entry point, the breakpoint doesn't trigger. Fix this by reverting commit cd919f5533c, and setting the breakpoint on ${func}_label instead. Tested on x86_64-linux and ppc64le-linux.
2022-09-12[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clangTom de Vries2-23/+62
When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run into: ... (gdb) break *compdir_missing__ldir_missing__file_basename^M Breakpoint 2 at 0x400580^M (gdb) continue^M Continuing.^M ^M Breakpoint 2, 0x0000000000400580 in \ compdir_missing.ldir_missing.file_basename ()^M (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \ compdir_missing__ldir_missing__file_basename: continue to breakpoint: \ compdir_missing__ldir_missing__file_basename ... The problem is that the test-case uses labels outside functions, which is know to cause problem with clang, as documented in the comment for proc function_range. Fix this by using get_func_info instead. Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.
2022-09-11[gdb/symtab] Fix handling of DW_TAG_unspecified_typeTom de Vries5-4/+123
Currently, the test-case contained in this patch fails: ... (gdb) p (int) foo ()^M Invalid cast.^M (gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo () ... because DW_TAG_unspecified_type is translated as void. There's some code in read_unspecified_type that marks the type as stub, but that's only active for ada: ... if (cu->lang () == language_ada) type->set_is_stub (true); ... Fix this by: - marking the type as a stub for all languages, and - handling the stub return type case in call_function_by_hand_dummy. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29558
2022-09-08Fix hardware watchpoint check in test gdb.base/watchpoint-reuse-slot.expCarl Love1-1/+11
This test generates 48 failures on Power 9 when testing with HW watchpoints enabled. Note HW watchpoint support is disabled on Power 9 due to a HW bug. The skip_hw_watchpoint_tests proc must be used to correctly determine if the processor supports HW watchpoints. This patch replaces the [target_info exists gdb,no_hardware_watchpoints] with the skip_hw_watchpoint_tests check. This patch was tested on Power 9, Power 10 and X86-64 with no regressions.
generated by cgit v1.1 at 2025-01-13 06:56:40 +0000