aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2024-10-14gdb/testsuite: fix gdb.multi/inferior-specific-bp.expGuinevere Larsen1-1/+2
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations", started checking if GDB correctly relocates a breakpoint from inferior 1's declaration of the function "bar" to inferior 2's declaration. Unfortunately, inferior 2 never calls bar in its regular execution, and because of that, clang would optimize that whole function away, making it so there is no location for the breakpoint to be relocated to. This commit changes the .c file so that the function is not optimized away and the test fully passes with clang. It is important to actually call bar instead of using __attribute__((used)) because the latter causes the breakpoint locations to be inverted, 3.1 belongs to inferior 2 and 3.2 belongs to inferior 1, which will cause an unrelated failure. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-10[gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linuxTom de Vries1-0/+18
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into: ... (gdb) awatch a^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint rwatch b^M Can't set read/access watchpoint when hardware watchpoints are disabled.^M (gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint continue^M Continuing.^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M (gdb) FAIL: $exp: continue until exit ... Using "maint info break", we can see that the two failed attempts to set a watchpoint each left behind a stale "watchpoint scope" breakpoint: ... -5 watchpoint scope del y 0xf7ec569a inf 1 -5.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 -6 watchpoint scope del y 0xf7ec569a inf 1 -6.1 y 0xf7ec569a inf 1 stop only in stack frame at 0xfffef4f8 ... The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the same happens if we: - have can-use-hw-watchpoints == 1, - set one of the watchpoints, and - continue to exit. The problem is missing symbol info on libc which is supposed to tell which code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV disappears. Extend the test-case to check the "maint info break" command before and after the two failed attempts, to make sure that we catch the stale "watchpoint scope" breakpoints also on x86_64-linux. Fix this in watch_command_1 by moving creation of the "watchpoint scope" breakpoint after the call to update_watchpoint. Tested on x86_64-linux. PR breakpoints/31860 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
2024-10-10[gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clangTom de Vries2-31/+78
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: ... FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 ... The problem is that the debug info produced by clang does not contain any references to enumerators val1 and val2, or the corresponding enumeration types. Instead, the variables u1 and u2 are considered to be simply of type int: ... <1><fb>: Abbrev Number: 2 (DW_TAG_variable) <fc> DW_AT_name : u1 <fd> DW_AT_type : <0x106> <101> DW_AT_external : 1 <103> DW_AT_location : (DW_OP_addrx <0>) <1><106>: Abbrev Number: 3 (DW_TAG_base_type) <107> DW_AT_name : int <108> DW_AT_encoding : 5 (signed) <109> DW_AT_byte_size : 4 <1><10a>: Abbrev Number: 2 (DW_TAG_variable) <10b> DW_AT_name : u2 <10c> DW_AT_type : <0x106> <110> DW_AT_external : 1 <112> DW_AT_location : (DW_OP_addrx <0x1>) ... Fix this by checking whether val1 and val2 are present in the cooked index before checking whether they have the correct parent. This cannot be expressed efficiently with gdb_test_lines, so factor out gdb_get_lines and use that instead. The test-case still calls "maint print objfiles" twice, but the first time is for have_index. We should probably use a gdb_caching_proc for this. Tested on aarch64-linux. Reported-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Keith Seitz <keiths@redhat.com> Tested-By: Guinevere Larsen <guinevere@redhat.com>
2024-10-10[gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1Tom de Vries5-6/+15
I ran the testsuite in an environment simulating a stressed system in combination with check-read1. This exposes a few more FAILs. Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. Tested on x86_64-linux.
2024-10-09[gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1Tom de Vries1-7/+21
On aarch64-linux, with make target check-read1, I run into: ... (gdb) info reg vector^M ... d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout) 0, u = 0, s = 0}^M ... The problem is that while (as documented) the corresponding gdb_test_multiple doesn't work for vector registers, it doesn't skip them either. This causes the timeout, and it also causes the registers after a vector register not to be found. Fix this by using -lbl style matching. Make which reggroups and registers are found more explicit using verbose -log, which makes us notice that regnames with underscores are skipped, so fix that as well. While we're at it, this: ... set invalid_register_re "Invalid register .*" ... and this: ... -re $invalid_register_re { fail "$test (unexpected invalid register response)" } ... means that the prompt may or may not be consumed. Fix this by limiting the regexp to one line, and using exp_continue. While we're at it, improve readability of the complex regexp matching a single register by factoring out regexps. Tested on aarch64-linux and x86_64-linux.
2024-10-08Use ui-out tables in "maint print user-regs"Tom Tromey1-1/+1
This changes "maint print user-regs" to use ui-out tables rather than printfs. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-08Use ui-out tables for info proc mappingsTom Tromey1-1/+1
This changes a few implementations of "info proc mappings" to use ui-out tables rather than printf. Note that NetBSD and FreeBSD also use printfs here, but since I can't test these, I didn't update them. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-08[gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1Tom de Vries1-17/+5
When running test-case gdb.base/break-interp.exp with check-read1, I run into: ... (gdb) info files^M ... 0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout) pieNO.d/libc.so.6^M ... The code has two adaptations to deal with the large output: - nested gdb_test_multiple, and - an exp_continue in the inner gdb_test_multiple. The former seems unnecessary, and the latter doesn't trigger often enough because of an incomplete hex number regexp, causing the timeout. Get rid of both of these, and use -lbl instead. Tested on x86_64-linux.
2024-10-08gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locationsAndrew Burgess4-2/+93
The commit: commit 6cce025114ccd0f53cc552fde12b6329596c6c65 Date: Fri Mar 3 19:03:15 2023 +0000 gdb: only insert thread-specific breakpoints in the relevant inferior added a couple of calls to breakpoint::clear_locations() inside update_breakpoint_locations(). The intention of these calls was to avoid leaving redundant locations around when a thread- or inferior-specific breakpoint was switched from one thread or inferior to another. Without the clear_locations() calls the tests gdb.multi/tids.exp and gdb.multi/pending-bp.exp have some failures. A b/p is changed such that the program space it is associated with changes. This triggers a call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be the new program space. As a result GDB correctly calculates the new locations and adds these to the breakpoint, but the old locations, in the old program space, are incorrectly retained. The call to clear_locations() solves this by deleting the old locations. However, while working on another patch I realised that the approach taken here is not correct. The FILTER_PSPACE argument passed to breakpoint_re_set_one() and then on to update_breakpoint_locations() might not be the program space to which the breakpoint is associated. Consider this example: (gdb) file /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) start Temporary breakpoint 1 at 0x401198: file hello.c, line 18. Starting program: /tmp/hello.x Temporary breakpoint 1, main () at hello.c:18 18 printf ("Hello World\n"); (gdb) break main thread 1 Breakpoint 2 at 0x401198: file hello.c, line 18. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000401198 in main at hello.c:18 stop only in thread 1 (gdb) add-inferior -exec /tmp/hello.x [New inferior 2] Added inferior 2 on connection 1 (native) Reading symbols from /tmp/hello.x... (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y <PENDING> main stop only in thread 1.1 Notice that after creating the second inferior and loading a file the thread-specific breakpoint was incorrectly made pending. Loading the exec file in the second inferior triggered a call to breakpoint_re_set() with the new, second, program space as the current_program_space. This program space ends up being passed to update_breakpoint_locations(). In update_breakpoint_locations this condition is true: if (all_locations_are_pending (b, filter_pspace) && sals.empty ()) and so we end up discarding all of the locations for this breakpoint, making the breakpoint pending. What we really want to do in update_breakpoint_locations() is, for thread- or inferior- specific breakpoints, delete any locations which are associated with a program space that this breakpoint is NOT associated with. But then I realised the answer was easier than that. The ONLY time that a b/p can have locations associated with the "wrong" program space like this is at the moment we change the thread or inferior the b/p is associated with by calling breakpoint_set_thread() or breakpoint_set_inferior(). And so, I think the correct solution is to hoist the call to clear_locations() out of update_breakpoint_locations() and place a call in each of the breakpoint_set_{thread,inferior} functions. I've done this, and added a couple of new tests. All of which are now passing. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnowTom de Vries1-6/+2
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and make target check-read1: ... $ ( cd build/gdb; \ make check-read1 \ RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" ) ... I run into: ... (gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1 print *the_local_var^M $1 = (n => 2)^M (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded ... The problem is that the corresponding gdb_test_multiple uses line-by-line matching (using -lbl) which doesn't work well with the multiline pattern matching both the prompt and the line before it: ... -re -wrap ".* = \\\(n => $decimal\\\)" { ... Fix this by making it a one-line pattern: ... -re -wrap "" { ... While we're at it, replace an if-then-pass-else-fail with a gdb_assert. Tested on aarch64-linux.
2024-10-08[gdb/symtab] Fix parent of enumeratorTom de Vries1-0/+15
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent: ... [27] ((cooked_index_entry *) 0x7fbbb4002ef0) name: val1 canonical: val1 qualified: val1 DWARF tag: DW_TAG_enumerator flags: 0x0 [] DIE offset: 0x124 parent: ((cooked_index_entry *) 0) ... This happens here in cooked_indexer::index_dies: ... info_ptr = recurse (reader, info_ptr, is_enum_class ? this_entry : parent_entry, fully); ... when we're passing down a nullptr parent_entry, while the parent of this_entry is deferred. Fix this in cooked_indexer::index_dies by passing down a deffered parent instead, such that we get: ... [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M name: val1^M canonical: val1^M qualified: ns::val1^M DWARF tag: DW_TAG_enumerator^M flags: 0x0 []^M DIE offset: 0x124^M parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-08[gdb/contrib] Add more separators in spellcheck.shTom de Vries2-2/+2
Add two more separators in spellcheck.sh: colon and comma. Doing so triggers the "inbetween->between" rule, which gives an incorrect result. Override this with "inbetween->between, in between, in-between" [1], in a new file gdb/contrib/common-misspellings.txt. Fix the following common misspellings: ... everytime -> every time sucess -> success thru -> through transfered -> transferred inbetween -> between, in between, in-between ... Verified with spellcheck.sh. Tested on x86_64-linux. [1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
2024-10-07[gdb/testsuite] Fix gdb.python/py-inferior.exp with -fsanitize=threadTom de Vries2-2/+4
With a gdb build with -fsanitize=thread, and test-case gdb.python/py-inferior.exp I run into: ... (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \ maximum supported size of 0x10000000000^M ... There's already a workaround for this using ASAN_OPTIONS, and apparently the same is needed for TSAN_OPTIONS. Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS. Likewise in gdb.dap/memory.exp. Tested on x86_64-linux.
2024-10-06gdb/m2: add builtin procedure function ADRGaius Mulley1-0/+32
This patch introduces ADR to the Modula-2 language interface. It return the address of the parameter supplied. The patch also contains a dejagnu test for ADR. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-10-06[gdb] Rerun spellcheck.shTom de Vries1-2/+2
Fix the following common misspellings: ... completetion -> completion inital -> initial ...
2024-10-06[gdb] Fix more common misspellingsTom de Vries3-3/+3
Fix the following common misspellings: ... addres -> address, adders behavour -> behavior, behaviour intented -> intended, indented ther -> there, their, the throught -> thought, through, throughout ... Tested on x86_64-linux.
2024-10-06[gdb] Fix common misspellingsTom de Vries52-64/+64
Fix the following common misspellings: ... accidently -> accidentally additonal -> additional addresing -> addressing adress -> address agaisnt -> against albiet -> albeit arbitary -> arbitrary artifical -> artificial auxillary -> auxiliary auxilliary -> auxiliary bcak -> back begining -> beginning cannonical -> canonical compatiblity -> compatibility completetion -> completion diferent -> different emited -> emitted emiting -> emitting emmitted -> emitted everytime -> every time excercise -> exercise existance -> existence fucntion -> function funtion -> function guarentee -> guarantee htis -> this immediatly -> immediately layed -> laid noone -> no one occurances -> occurrences occured -> occurred originaly -> originally preceeded -> preceded preceeds -> precedes propogate -> propagate publically -> publicly refering -> referring substract -> subtract substracting -> subtracting substraction -> subtraction taht -> that targetting -> targeting teh -> the thier -> their thru -> through transfered -> transferred transfering -> transferring upto -> up to vincinity -> vicinity whcih -> which whereever -> wherever wierd -> weird withing -> within writen -> written wtih -> with doesnt -> doesn't ... Tested on x86_64-linux.
2024-09-30Add line-number stylingTom Tromey4-9/+12
This patch adds separate styling for line numbers. That is, whenever gdb prints a source line number, it uses this style. v2 includes a change to ensure that %ps works in query. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-09-30gdb: fix filename completion in the middle of a lineAndrew Burgess1-0/+163
I noticed that filename completion in the middle of a line doesn't work as I would expect it too. For example, assuming '/tmp/filename' exists, and is the only file in '/tmp/' then when I do the following: (gdb) file "/tmp/filen<TAB> GDB completes to: (gdb) file "/tmp/filename" But, if I type this: (gdb) file "/tmp/filen "xxx" Then move the cursor to the end of '/tmp/filen' and press <TAB>, GDB will complete the line to: (gdb) file "/tmp/filename "xxx" But GDB will not insert the trailing double quote character. The reason for this is found in readline/readline/complete.c in the function append_to_match. This is the function that appends the trailing closing quote character, however, the closing quote is only inserted if the cursor (rl_point) is at the end (rl_end) of the line being completed. In this patch, what I do instead is add the closing quote in the function gdb_completer_file_name_quote, which is called from readline through the rl_filename_quoting_function hook. The docs for rl_filename_quoting_function say (see 'info readline'): "... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one completion match, or 'MULT_MATCH'. Some functions use this to decide whether or not to insert a closing quote character. ..." This is exactly what I'm doing in this patch, and clearly this is not an unusual choice. Now after completing a filename that is not at the end of the line GDB will add the closing quote character if appropriate. I have managed to write some tests for this. I send a line of text to GDB which includes a partial filename followed by a trailing string, I then send the escape sequence to move the cursor left, and finally I send the tab character. Obviously, expect doesn't actually see the complete output with the extra text "in place", instead expect sees the original line followed by some escape sequences to reflect the cursor movement, then an escape sequence to indicate that text is being inserted in the middle of a line, followed by the new characters ... it's a bit messy, but I think it holds together. Reviewed-By: Tom Tromey <tom@tromey.com>
2024-09-30gdb: fix for completing a second filename for a commandAndrew Burgess1-102/+120
After the recent filename completion changes I noticed that the following didn't work as expected: (gdb) file "/path/to/some/file" /path/to/so<TAB> Now, I know that the 'file' command doesn't actually take multiple filenames, but currently (and this was true before the recent filename completion changes too) the completion function doesn't know that the command only expects a single filename, and should complete any number of filenames. And indeed, this works: (gdb) file "/path/to/some/file" "/path/to/so<TAB> In this case I quoted the second path, and now GDB is happy to offer completions. It turns out that the problem in the first case is an off-by-one bug in gdb_completer_file_name_char_is_quoted. This function tells GDB if a character within the line being completed is escaped or not. An escaped character cannot be a word separator. The algorithm in gdb_completer_file_name_char_is_quoted is to scan forward through the line keeping track of whether we are inside double or single quotes, or if a character follows a backslash. When we find an opening quote we skip forward to the closing quote and then check to see if we skipped over the character we are looking for, if we did then the character is within the quoted string. The problem is that this "is character inside quoted string" check used '>=' instead if '>'. As a consequence a character immediately after a quoted string would be thought of as inside the quoted string. In our first example this means that the single white space character after the quoted string was thought to be quoted, and was not considered a word breaking character. As such, GDB would not try to complete the second path. And indeed, if we tried this: (gdb) file "/path/to/some/file" /path/to/so<TAB> That is, place multiple spaces after the first path, then GDB would consider the first space as quoted, but the second space is NOT quoted, and would be a word break. Now GDB does complete the second path. By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this bug is resolved, now the original example works and GDB will correctly complete the second path. For testing I've factored out the core of one testing proc, and I now run those tests multiple times, once with no initial path, once with an initial path in double quotes, once with an initial path in single quotes, and finally, with an unquoted initial path. Reviewed-By: Tom Tromey <tom@tromey.com>
2024-09-30gdb, testsuite: clean duplicate header includesGerlicher, Klaus8-9/+0
Some of the gdb and testsuite files double include some headers. While all headers use include guards, it helps a bit keeping the code base tidy. No functional change. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-09-27Re-run 'isort' on gdb testsTom Tromey1-0/+1
Re-running 'isort' (via pre-commit) showed that the file py-read-memory-leak.py (from the gdb test suite) needed a small patch.
2024-09-26gdb/testsuite: test for memory leaks in gdb.Inferior.read_memory()Andrew Burgess3-0/+163
For a long time Fedora GDB has carried an out of tree patch which checks for memory leaks in gdb.Inferior.read_memory(). At one point in the distant past GDB did have a memory leak in this code, but this was first fixed in commit: commit 655e820cf9a039ee55325d9e1f8423796d592b4b Date: Wed Mar 28 17:38:07 2012 +0000 * python/py-inferior.c (infpy_read_memory): Remove cleanups and explicitly free 'buffer' on exit paths. Decref 'membuf_object' before returning. And the code has changed a lot since then, but the leak is still fixed. Unfortunately, this commit didn't have any associated tests. The original Fedora test wasn't really suitable for upstream, it was reading /proc/PID/... to figure out if there was a leak or not. However, we already have gdb.python/py-inferior-leak.exp in upstream GDB, which makes use of the Python tracemalloc module to check for memory leaks in a corner of the Python API, so I figured it wouldn't hurt to rewrite the test in the same style. And so here is a test for a bug which was closed 12 years ago. This detects if the gdb.Inferior.read_memory() call leaks any memory. I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last line which currently looks like this: return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ()); and instead doing: return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ()); The use of "release" here will mean we no longer decrement the reference count on membuf_obj before returning from the function. As a consequence the membuf_obj will not be garbage collected. With this hack in place the new test will fail. The Python script in the new test is mostly a copy&paste from py-inferior-leak.py with the core changed to do a memory read instead of inferior creation. I did consider rewriting both tests into a single file, maybe, py-memory-leak.py, which would make it easier to add additional similar tests in the future. For now I've held off doing that, but if this gets merged then I _might_ revisit this idea. If folk feel that this new test should only be accepted if I do this rewrite then let me know and I can get that done. On copyright date ranges: The .exp and .py scripts are new enough for this commit that I've dated them 2024. The .c source script is lifted directly from the old Fedora patch, so I've retained the original 2014 start date for that file only. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-25[gdb/python] Make sure python sys.exit makes gdb exitTom de Vries1-0/+69
With gdb 15.1, python sys.exit no longer makes gdb exit: ... $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? Python Exception <class 'SystemExit'>: 2 Error occurred in Python: 2 $1 = 123 0 ... This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python" command exception handling"), first available in gdb 15.1. This patch reverts to the old behaviour by handling PyExc_SystemExit in gdbpy_handle_exception, such what we have instead: ... $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? 2 ... Tested on x86_64-linux, with python 3.6 and 3.13. Tested-By: Guinevere Larsen <blarsen@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> PR python/31946 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
2024-09-25gdb/testsuite: format some Python filesSimon Marchi3-0/+3
Format with black. Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2
2024-09-25gdb, gdbserver, python, testsuite: Remove MPX.Schimpe, Christina12-1211/+4
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019. MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6) and glibc (since v2.35). Let's now remove MPX support in GDB completely. This includes the removal of: - MPX functionality including register support - deprecated mpx commands - i386 and amd64 implementation of the hooks report_signal_info and get_siginfo_type - tests - and pretty printer. We keep MPX register numbers to not break compatibility with old gdbservers. Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-09-25gdb, testsuite, python: Add missing imports.Schimpe, Christina3-1/+3
Removing the pretty printer (bound_registers.py) in the next commit leads to failures due to a missing import of 'gdb.printing': "AttributeError: module 'gdb' has no attribute 'printing'". Add this import to each file requiring it, as it's not imported by the pretty-printer anymore. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-09-24Fix typo in gdb.ada/complete.exp testTom Tromey1-1/+1
I noticed that two tests in gdb.ada/complete.exp are testing the same thing: the completion of "p pck.inne". The second such test has this comment: # A fully qualified package name I believe the intent here was to test "p pck.inner" (note the trailing "r"). This patch makes this change.
2024-09-24gdb: testsuite: Test whether PC register is expedited in ↵Thiago Jung Bauermann1-0/+33
gdb.server/server-run.exp One thing GDB always does when the inferior stops is finding out where it's stopped at, by way of querying the value of the program counter register. To save a packet round trip, the remote target can send the PC value (often alongside other frequently consulted registers such as the stack pointer) in the stop reply packet as an "expedited register". Test that this is actually done for the targets where gdbserver is supposed to. Extend the "maintenance print remote-registers" command output with an "Expedited" column which says "yes" if the register was seen by GDB in the last stop reply packet it received, and is left blank otherwise. Tested for regressions on aarch64-linux-gnu native-extended-remote. The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and x86_64-linux-gnu native-remote and native-extended-remote targets. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-09-24btrace: Add support for IRET events.Felix Willgerodt2-1/+5
This is similar to the previous events that we added. Approved-By: Markus Metzger <markus.t.metzger@intel.com>
2024-09-24btrace: Add support for interrupt events.Felix Willgerodt5-0/+237
Newer Intel CPUs support recording asynchronous events in the PT trace. Libipt also recently added support for decoding these. This patch adds support for interrupt events, based on the existing aux infrastructure. GDB can now display such events during the record instruction-history and function-call-history commands. Subsequent patches will add the rest of the events currently supported. Approved-By: Markus Metzger <markus.t.metzger@intel.com>
2024-09-24[gdb/cli] Show readline wrapping mode for maint info screenTom de Vries1-6/+22
With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC as used in commit 250f1bbaf33 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled"), we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in PR testsuite/31201: ... (gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678 ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout) ... The test-case expects wrapping, but that's disabled by horizontal-scroll-mode. Add a new line to "maint info screen", that describes the current readline wrapping mode, and use it in the test-case to handle the different cases. The reported values for the wrapping mode are as follows. Unsupported because of running in batch mode: ... $ gdb -q -batch -ex "maint info screen" Readline wrapping mode: unsupported (gdb batch mode). ... Unsupported because the terminal is not capable to move the cursor up: ... $ TERM=dumb gdb -q -ex "maint info screen" -ex q Readline wrapping mode: unsupported (terminal is not Cursor Up capable). ... Disabled by horizontal-scroll-mode: ... $ grep horizontal-scroll-mode ~/.inputrc set horizontal-scroll-mode on $ gdb -q -ex "maint info screen" -ex q Readline wrapping mode: disabled (horizontal-scroll-mode). ... Wrap done by readline because terminal is not auto wrap capable: ... $ TERM=ansi gdb -q -ex "maint info screen" -ex q Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved). ... Wrap done by terminal autowrap: ... $ TERM=xterm gdb -q -ex "maint info screen" -ex q Readline wrapping mode: terminal (terminal is auto wrap capable). ... Tested on x86_64-linux. Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de> Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
2024-09-24[gdb/symtab] Fix segfault on invalid debug infoTom de Vries1-0/+51
While looking at PR symtab/31478 (a problem in the cooked indexer with invalid dwarf) it occurred to me that I could trigger a similar problem using: ... Compilation Unit @ offset 0xb2: Length: 0x1f (32-bit) Version: 4 Abbrev Offset: 0x6c Pointer Size: 8 <0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit) <be> DW_AT_language : 2 (non-ANSI C) <1><bf>: Abbrev Number: 2 (DW_TAG_subprogram) <c0> DW_AT_low_pc : 0x4004a7 <c8> DW_AT_high_pc : 0x4004b2 <d0> DW_AT_specification: <0xd5> <1><d4>: Abbrev Number: 0 Compilation Unit @ offset 0xd5: Length: 0x7 (32-bit) Version: 4 Abbrev Offset: 0x7f Pointer Size: 8 ... and indeed I get: ... $ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2 Fatal signal: Segmentation fault ... The problem is that we're calling prepare_one_comp_unit with cu == nullptr and comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists: ... cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false, m_index_storage->get_abbrev_cache ()); prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die, language_minimal); ... Fix this by bailing out for various types of dummy CUs: ... if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr || !new_reader.comp_unit_die->has_children) return nullptr; ... Also make sure in scan_attributes that this triggers a dwarf error: ... $ gdb -q -batch dw2-inter-cu-error-2 DWARF Error: cannot follow reference to DIE at 0xd5 \ [in module dw2-inter-cu-error-2] ... With target board readnow, the test-case triggers an assertion failure in follow_die_offset, so fix this by throwing the same dwarf error. While we're at it, make the other check for dummy CUs in cooked_indexer::ensure_cu_exists more robust by adding an intermediate test for comp_unit_die: ... - if (result->dummy_p || !result->comp_unit_die->has_children) + if (result->dummy_p || result->comp_unit_die == nullptr + || !result->comp_unit_die->has_children) return nullptr; ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-24[gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.expTom de Vries1-0/+75
Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol from an unused PU is not accessible. Passes with the relevant target boards: - unix (using the cooked index), - readnow (using no index at all), - cc-with-gdb-index (using .gdb_index), and - cc-with-debug-names (using .debug_names). Tested on x86_64-linux.
2024-09-23testsuite, threads: fix LD_LIBRARY_PATH in 'tls-sepdebug.exp'Rohr, Stephan1-4/+9
Some compilers (e.g. the Intel compiler) may dynamically link against dependencies. The test uses the 'set env' command to set the LD_LIBRARY_PATH to a test specific value. Update the 'set env' command to also provide the users LD_LIBARY_PATH to gdb. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-23[gdb/testsuite] Avoid large timeout in gdb.base/checkpoint.expTom de Vries1-18/+32
I ran the testsuite in an environment simulating a stressed system, and the only test-cases that timed out in gdb.base were gdb.base/checkpoint.exp and gdb.base/checkpoint-ns.exp (which includes gdb.base/checkpoints.exp). In test-case gdb.base/checkpoint.exp there's a part where the timeout is increased with 120 seconds (in the default case that's from 10 to 130), to accommodate for a single command creating 600+ checkpoints. Instead, rewrite the test to present a gdb prompt each time a checkpoint is created, for which the default timeout is sufficient. Also ensure that the amount of checkpoints added is exactly 600 rather than 600+. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-23Automatically add types to Python modulesTom Tromey1-0/+9
PR python/32163 points out that various types provided by gdb are not added to the gdb module, so they aren't available for interactive inspection. I think this is just an oversight. This patch fixes the problem by introducing a new helper function that both readies the type and then adds it to the appropriate module. The patch also poisons PyType_Ready, the idea being to avoid this bug in the future. v2: * Fixed a bug in original patch in gdb.Architecture registration * Added regression test for the types mentioned in the bug Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2024-09-23[gdb/testsuite] Fix timeout in gdb.fortran/info-types.expTom de Vries3-6/+6
When running the testsuite in an enviroment that simulates a stressed system, I ran into a timeout in test-case gdb.fortran/info-types.exp: ... (gdb) info types^M FAIL: gdb.fortran/info-types.exp: info types (timeout) ... This is mainly due the presence of glibc debug info. With it installed, I get: ... $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null real 0m35.969s user 0m38.231s sys 0m1.007s ... and without: ... $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null real 0m4.782s user 0m5.014s sys 0m0.304s ... Fix this by not running to main, which gets us: ... $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null real 0m0.808s user 0m0.789s sys 0m0.137s ... Likewise in gdb.mi/mi-sym-info.exp and gdb.mi/mi-complete.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-23[gdb/testsuite] Fix failure in gdb.threads/signal-sigtrap.expTom de Vries2-2/+34
The test-case gdb.threads/signal-sigtrap.exp: - installs a signal handler called sigtrap_handler for SIGTRAP, - sets a breakpoint on sigtrap_handler, and - expects the breakpoint to trigger after issuing "signal SIGTRAP". Usually, that happens indeed: ... (gdb) signal SIGTRAP^M Continuing with signal SIGTRAP.^M ^M Thread 1 "signal-sigtrap" hit Breakpoint 2, sigtrap_handler (sig=5)^M 28 }^M (gdb) PASS: $exp: sigtrap thread 1: signal SIGTRAP reaches handler ... Occasionally, I run into this failure on openSUSE Tumbleweed: ... (gdb) signal SIGTRAP^M Continuing with signal SIGTRAP.^M ^M Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M __pthread_create_2_1 () at pthread_create.c:843^M (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler ... AFAIU, the problem is in the situation that is setup before issuing that command, by running to a breakpoint in thread_function: ... void *thread_function (void *arg) { return NULL; } int main (void) { pthread_t child_thread; signal (SIGTRAP, sigtrap_handler); pthread_create (&child_thread, NULL, thread_function, NULL); pthread_join (child_thread, NULL); return 0; } ... In the passing case, thread 2 is stopped in thread_function, and thread 1 is stopped somewhere in pthread_join: ... (gdb) info threads^M Id Target Id Frame ^M 1 Thread ... (LWP ...) "signal-sigtrap" __futex_abstimed_wait_common64 () * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () ... In the failing case, thread 2 is stopped in thread_function, but thread 1 is stopped somewhere in pthread_create: ... (gdb) info threads^M Id Target Id Frame ^M 1 Thread ... (LWP ...) "signal-sigtrap" __GI___clone3 () * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () ... What I think happens is that pthread_create blocks SIGTRAP at some point, and if the "signal SIGTRAP" command is issued while that is the case, the signal becomes pending and consequently there's no longer a guarantee that the signal will be delivered to the inferior. Instead the signal will be handled by gdb like this: ... (gdb) info signals SIGTRAP Signal Stop Print Pass to program Description SIGTRAP Yes Yes No Trace/breakpoint trap ... Fix this by adding a barrier that ensures that pthread_create is done before we issue the "signal SIGTRAP" command. Likewise in test-case gdb.threads/signal-command-handle-nopass.exp. Using the fixed test-case, I tested my theory by explicitly blocking SIGTRAP: ... + sigset_t old_ss, new_ss; + sigemptyset (&new_ss); + sigaddset (&new_ss, SIGTRAP); + sigprocmask (SIG_BLOCK, &new_ss, &old_ss); + /* Make sure that pthread_create is done once the breakpoint on thread_function triggers. */ pthread_barrier_wait (&barrier); pthread_join (child_thread, NULL); + sigprocmask (SIG_SETMASK, &old_ss, NULL); ... and managed to reproduce the same failure: ... (gdb) signal SIGTRAP^M Continuing with signal SIGTRAP.^M [Thread 0x7ffff7c00700 (LWP 13254) exited]^M ^M Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M 0x00007ffff7c80056 in __GI___sigprocmask () sigprocmask.c:39^M (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler ... Tested on x86_64-linux. PR testsuite/26867 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26867
2024-09-23[gdb/testsuite] Fix gdb.base/return.exp on arm-linuxTom de Vries1-2/+2
After doing pre-commit testing of some patch on arm-linux, the Linaro CI reported: ... FAIL: 1 regressions: 1 improvements regressions.sum: === gdb tests === Running gdb:gdb.base/return.exp ... ERROR: no fileid for ccd235fdc9bf improvements.sum: === gdb tests === Running gdb:gdb.base/return.exp ... ERROR: no fileid for 017e9b314c5a ... The problem is the call to allow_float_test. It calls gdb_exit (for arm-linux only), and consequently kills the gdb instance setup by prepare_for_testing: ... if { [prepare_for_testing "failed to prepare" "return"] } { return -1 } set allow_float_test [allow_float_test] ... Fix this by moving the call to allow_float_test to before prepare_for_testing. Tested on arm-linux and x86_64-linux.
2024-09-23[gdb/testsuite] Make parse_args error out on remaining argsTom de Vries11-26/+46
I noticed that introducing a typo here in gdb.mi/mi-breakpoint-changed.exp: ... set bp_re [mi_make_breakpoint \ - -number $bp_nr \ + -nunber $bp_nr \ -type dprintf \ -func marker \ -script [string_to_regexp {["printf \"arg\" \""]}]] ... didn't make the test fail. Proc mi_make_breakpoint uses parse_args, but does not check the remaining args as parse_args suggests: ... proc parse_args { argset } { parse_list 2 args $argset "-" false # The remaining args should be checked to see that they match the # number of items expected to be passed into the procedure } ... We could add the missing check in mi_make_breakpoint, but I think the problem is likely to occur again because the name parse_args does not suggest that further action is required. Fix this instead by: - copying proc parse_args to new proc parse_some_args, - adding new proc check_no_args_left, and - calling check_no_args_left in parse_args. Also be more strict in a few places where we do lassign for remaining args: ... lassign $args a b ... There may be more arguments left in $args, so check that that's not the case using check_no_args_left: ... set args [lassign $args a b] check_no_args_left ... Fix a few test-cases that trigger on the stricter checking. Tested on x86_64-linux. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> PR testsuite/32129 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129
2024-09-23[gdb/testsuite] Fix gdb.base/empty-host-env-vars.expTom de Vries1-23/+9
On aarch64-linux (debian testing) with test-case gdb.base/empty-host-env-vars.exp I ran into: ... (gdb) show index-cache directory^M The directory of the index cache is "/home/linux/.cache/gdb".^M (gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory ... Without changing any environment variables, the value of the index-cache dir is: ... $ gdb -q -batch -ex "show index-cache directory" The directory of the index cache is "/home/linux/.cache/gdb". ... and the expectation of the test-case is that setting HOME to empty will produce an empty dir, but what it actually produces is: ... $ HOME= gdb -q -batch -ex "show index-cache directory" The directory of the index cache is "/home/linux/.cache/gdb". ... There's nothing wrong with that behaviour, the dir is simply constructed using XDG_CACHE_HOME which happens to be explictly set to its default value $HOME/.cache [1]: ... $ echo $XDG_CACHE_HOME /home/linux/.cache ... and indeed also setting that variable to empty gets us the expected empty dir: ... $ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory" gdb: warning: Couldn't determine a path for the index cache directory. The directory of the index cache is "". ... Furthermore, the test-case assumption that setting variables to empty either produces the original dir or an empty dir is incorrect. Say that XDG_CACHE_HOME has a non-default value: ... $ echo $XDG_CACHE_HOME /home/linux/my-xdg-cache-home $ gdb -q -batch -ex "show index-cache directory" The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb". ... then setting that variable to empty: ... $ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory" The directory of the index cache is "/home/linux/.cache/gdb". ... does change the value of the dir. Fix this by making the test-case less specific. While we're at it, factor out regexps re_pre and re_post to make regexps more readable, and use string_to_regexp to reduce quoting. Tested on aarch64-linux. PR testsuite/32132 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132 [1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables
2024-09-23[gdb/testsuite] Fix gdb.base/attach-deleted-exec.exp with NFSTom de Vries1-3/+21
With test-case gdb.base/attach-deleted-exec.exp I ran into: ... (gdb) attach 121552^M Attaching to process 121552^M Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^M Reading symbols from /lib64/libm.so.6...^M (No debugging symbols found in /lib64/libm.so.6)^M Reading symbols from /lib64/libc.so.6...^M (No debugging symbols found in /lib64/libc.so.6)^M Reading symbols from /lib64/ld64.so.2...^M (No debugging symbols found in /lib64/ld64.so.2)^M 0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M (gdb) FAIL: $exp: attach to process with deleted executable .... The .nfs file indicates: - that the file has been removed on the NFS server, and - that the file is still open on the NFS client. Fix this by detecting this situation, and declaring the test for filename /proc/PID/exe unsupported. Tested on: - x86_64-linux (setup without NFS) - ppc64le-linux (setup with NFS) PR testsuite/32130 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130
2024-09-23[gdb/testsuite] Fix gdb.trace/entry-values.exp on riscv64-linuxTom de Vries1-0/+2
On riscv64-linux, with test-case gdb.trace/entry-values.exp I run into: ... (gdb) disassemble bar^M Dump of assembler code for function bar:^M 0x0000000000000646 <+0>: addi sp,sp,-48^M 0x0000000000000648 <+2>: sd ra,40(sp)^M 0x000000000000064a <+4>: sd s0,32(sp)^M 0x000000000000064c <+6>: addi s0,sp,48^M 0x000000000000064e <+8>: mv a5,a0^M 0x0000000000000650 <+10>: sw a5,-36(s0)^M 0x0000000000000654 <+14>: li a5,2^M 0x0000000000000656 <+16>: sw a5,-20(s0)^M 0x000000000000065a <+20>: lw a4,-20(s0)^M 0x000000000000065e <+24>: lw a5,-36(s0)^M 0x0000000000000662 <+28>: mv a1,a4^M 0x0000000000000664 <+30>: mv a0,a5^M 0x0000000000000666 <+32>: jal 0x628 <foo>^M 0x000000000000066a <+36>: mv a5,a0^M 0x000000000000066c <+38>: mv a0,a5^M 0x000000000000066e <+40>: ld ra,40(sp)^M 0x0000000000000670 <+42>: ld s0,32(sp)^M 0x0000000000000672 <+44>: addi sp,sp,48^M 0x0000000000000674 <+46>: ret^M End of assembler dump.^M (gdb) FAIL: gdb.trace/entry-values.exp: disassemble bar FAIL: gdb.trace/entry-values.exp: find the call or branch instruction offset in bar ... Fix this by setting call_insn to jal for riscv64. Tested on riscv64-linux and x86_64-linux.
2024-09-23[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.expTom de Vries1-1/+1
On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while I run into (edited for readability): ... (gdb) ^M <LOTS-OF-SPACES>-data-evaluate-expression $a^M -data-evaluate-^done,value="\"FIRST COMMAND\""^M expression $b(gdb) ^M ^M ^done,value="\"TEST COMPLETE\""^M (gdb) ^M PASS: $exp: args=: look for first command output, command length 236 FAIL: $exp: args=: look for second command output, command length 236 (timeout) ... This is more likely to trigger when running the test-case using taskset -c <cpu> (where in a big.little setup we pick a little cpu). The setup here is that the test-case issues these two commands at once: ... -data-evaluate-expression $a -data-evaluate-expression $b ... where the length of the first command is artificially increased by prefixing it with spaces, show as <LOTS-OF-SPACES> above. What happens is that gdb, after parsing the first command, executes it. Then the output of the first command intermixes with the echoing of the second command, which produces this line containing the first prompt: ... expression $b(gdb) ^M ... which doesn't match the \r\n prefix of the regexp supposed to consume the first prompt: ... -re "\r\n$mi_gdb_prompt" { ... Fix this by dropping the \r\n prefix. Tested on aarch64-linux. PR testsuite/29781 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781
2024-09-21[gdb/testsuite] Limit xfail in gdb.ada/call_pn.expTom de Vries1-2/+11
Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only necessary for gcc 8 and 9. Fix this by limiting the xfail to those releases. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-21[gdb/testsuite] Fix timeout in gdb.ada/call_pn.expTom de Vries1-1/+1
With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into this timeout: ... (gdb) maint expand-symtabs^M FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout) ... The timeout was related to running the cpu at base frequency of 400Mhz instead of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core). But when investigating the test-case I realized that the maint expand-symtabs could be limited to the source files, so use that to speed up the test-case. Tested on x86_64-linux. Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/32177 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177
2024-09-21[gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-casesTom de Vries3-32/+4
When running the testsuite in an enviroment simulating a stressed system, I ran into timeouts in three test-cases in gdb.dwarf2: - gdb.dwarf2/count.exp, - gdb.dwarf2/implptrconst.exp, and - gdb.dwarf2/implptrpiece.exp. In all three cases, -readnow is used which results in symtabs being expanded for the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2. We could address this by limiting the scope of -readnow to the executable, but after reviewing the test-cases there doesn't seem to be a clear reason to use -readnow. Fix this by dropping the -readnow. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-09-20gdb/testsuite: rework bp-cond-failure to not depend on inliningGuinevere Larsen2-20/+40
The test gdb.base/bp-cond-failure is implicitly expecting that the function foo will be inlined twice and gdb will be able to find 2 locations to place a breakpoint. When clang is used, gdb only finds one location which causes the test to fail. Since the test is not worried about handling breakpoints on inlined functions, but rather on the format of the message on a breakpoint condition fail, this seems like a false fail report. This commit reworks the test to be in c++, and uses function overloading to ensure that 2 locations will always be found. Empirical testing showed that, for clang, we will land on location 2 with the currest exp commands, no matter the order of the functions declared, whereas for gcc it depends on the order that functions were declared, so they are ordered to always land on the second location, this way we are able to hardcode it and check for it. Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-09-17gdb/testsuite: skip gdb.mi/dw2-ref-missing-frame.exp with clangGuinevere Larsen1-0/+10
The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set debug information by hand, using a .S file and assembly labels to get addresses. Unfortunately, clang will always re-arrange the global labels to be side by side, making high and low PC for CUs and functions be the same, and thus they will all be empty ranges. This makes the test fail, since we never technically enter the functions that we want to check. This commit skips that test when using clang. If we ever port this test to use the dwarf assembler, we can reenable it with clang. Approved-By: Tom Tromey <tom@tromey.com>