aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-05-15gdb/testsuite: Revert commit 843f4d93576eef02139f7b1b3fa1cea7b0f286f1Andrew Burgess2-20/+5
Revert this commit: commit 843f4d93576eef02139f7b1b3fa1cea7b0f286f1 Date: Tue May 12 17:38:17 2020 +0100 gdb/testsuite: Disable path and duplicate checks when parallel testing Now that this commit has landed: commit c959562d9ba0b2eaf240c601b2c2fd49c42c1f2f Date: Fri May 15 11:23:59 2020 +0100 contrib: Update dg-extract-results.* from gcc We can now make use of the mechanism for detecting paths in test names and duplicate test names, even when we run tests in parallel. gdb/testsuite/ChangeLog: * lib/check-test-names.exp: Remove code that prevents this file loading when tests are run in parallel.
2020-05-15Fix gdb.multi/multi-kill.expPedro Alves2-5/+12
The previous patch misssed declaring the 'testpid' array as namespace variable. While it at, might as well go back to having start_inferior refer to the "global" testpid, using "variable" too. gdb/testsuite/ChangeLog: 2020-05-15 Pedro Alves <palves@redhat.com> * gdb.multi/multi-kill.exp (start_inferior): Remove 'testpid' parameter. Refer to namespace variable directly. (testpid): Declare as namespace variable.
2020-05-15Fix global variable collision in gdb.multi/multi-kill.expPedro Alves2-5/+22
The new gdb.multi/multi-kill.exp testcase added an 'testpid' array, which may conflict with other global 'testpid' variables used by other testcases, resulting in: ... ERROR: tcl error sourcing /data/gdb_versions/devel/src/gdb/testsuite/gdb.multi/multi-kill.exp. ERROR: can't set "testpid(1)": variable isn't array while executing "set testpid($num) [get_integer_valueof "pid" -1]" or $ runtest gdb.threads/check-libthread-db.exp gdb.multi/multi-kill.exp ... Running /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.multi/multi-kill.exp ... Running /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/check-libthread-db.exp ... ERROR: tcl error sourcing /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/check-libthread-db.exp. ERROR: can't set "testpid": variable is array while executing "set testpid [spawn_id_get_pid $test_spawn_id]" ("uplevel" body line 8) Fix this with a namespace, like gdb.linespec/explicit.exp does. gdb/testsuite/ChangeLog: 2020-05-15 Pedro Alves <palves@redhat.com> * gdb.multi/multi-kill.exp: Wrap in namespace. (start_inferior): Add TESTPID parameter. Use it instead of the testpid global. (top level): Define empty TESTPID array, and pass it down to start_inferior.
2020-05-14Disable record btrace bts support for AMD processorsKevin Buettner2-0/+12
Some Intel processors implement a Branch Trace Store (BTS) which GDB uses for reverse execution support via the "record btrace bts" command. I have been unable to find a description of a similar feature in a recent (April 2020) AMD64 architecture reference: https://www.amd.com/system/files/TechDocs/40332.pdf While it is the case that AMD processors have an LBR (last branch record) bit in the DebugCtl MSR, it seems that it affects only four MSRs when enabled. The names of these MSRs are LastBranchToIP, LastBranchFromIP, LastIntToIP, and LastIntFromIP. I can find no mention of anything more extensive. While looking at an Intel architecture document, I noticed that Intel's P6 family from the mid-90s had registers of the same name. Therefore... This commit disables "record btrace bts" support in GDB for AMD processors. Using the test case from gdb.base/break.exp, the sessions below show the expected behavior (run on a machine with an Intel processor) versus that on a machine with an AMD processor. The AMD processor in question is reported as follows by "lscpu": AMD Ryzen Threadripper 2950X 16-Core Processor . Finally, I'll note that the AMD machine is actually a VM, but I see similar behavior on both the virtualization host and the VM. Intel machine - Desired behavior: [kevinb@mohave gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break Reading symbols from testsuite/outputs/gdb.base/break/break... (gdb) start Temporary breakpoint 1 at 0x401179: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 43. Starting program: /home/kevinb/sourceware-git/native-build/bld/gdb/testsuite/outputs/gdb.base/break/break Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd748, envp=0x7fffffffd758) at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:43 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */ (gdb) record btrace (gdb) b factorial Breakpoint 2 at 0x40121b: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 63. (gdb) c Continuing. Breakpoint 2, factorial (value=6) at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:63 63 if (value > 1) { /* set breakpoint 7 here */ (gdb) info record Active record target: record-btrace Recording format: Branch Trace Store. Buffer size: 64kB. Recorded 768 instructions in 22 functions (0 gaps) for thread 1 (process 19215). (gdb) record function-call-history 13 do_lookup_x 14 _dl_lookup_symbol_x 15 _dl_fixup 16 _dl_runtime_resolve_xsavec 17 atoi 18 strtoq 19 ____strtoll_l_internal 20 atoi 21 main 22 factorial (gdb) record instruction-history 759 0x00007ffff7ce0917 <____strtoll_l_internal+647>: pop %r15 760 0x00007ffff7ce0919 <____strtoll_l_internal+649>: retq 761 0x00007ffff7cdd064 <atoi+20>: add $0x8,%rsp 762 0x00007ffff7cdd068 <atoi+24>: retq 763 0x00000000004011b1 <main+75>: mov %eax,%edi 764 0x00000000004011b3 <main+77>: callq 0x401210 <factorial> 765 0x0000000000401210 <factorial+0>: push %rbp 766 0x0000000000401211 <factorial+1>: mov %rsp,%rbp 767 0x0000000000401214 <factorial+4>: sub $0x10,%rsp 768 0x0000000000401218 <factorial+8>: mov %edi,-0x4(%rbp) AMD machine - Wrong behavior: [kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break Reading symbols from testsuite/outputs/gdb.base/break/break... (gdb) start Temporary breakpoint 1 at 0x401179: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 43. Starting program: /mesquite2/sourceware-git/f32-master/bld/gdb/testsuite/outputs/gdb.base/break/break Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd5b8, envp=0x7fffffffd5c8) at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:43 43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */ (gdb) record btrace (gdb) b factorial Breakpoint 2 at 0x40121b: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 63. (gdb) c Continuing. Breakpoint 2, factorial (value=6) at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:63 63 if (value > 1) { /* set breakpoint 7 here */ (gdb) info record Active record target: record-btrace Recording format: Branch Trace Store. Buffer size: 64kB. warning: Recorded trace may be incomplete at instruction 7737 (pc = 0x405000). warning: Recorded trace may be incomplete at instruction 7739 (pc = 0x0). Recorded 7740 instructions in 46 functions (2 gaps) for thread 1 (process 1402911). (gdb) record function-call-history 37 ?? 38 values 39 some_enum_global 40 ?? 41 some_union_global 42 some_variable 43 ?? 44 [decode error (2): unknown instruction] 45 ?? 46 [decode error (2): unknown instruction] (gdb) record instruction-history 7730 0x0000000000404ff3: add %al,(%rax) 7731 0x0000000000404ff5: add %al,(%rax) 7732 0x0000000000404ff7: add %al,(%rax) 7733 0x0000000000404ff9: add %al,(%rax) 7734 0x0000000000404ffb: add %al,(%rax) 7735 0x0000000000404ffd: add %al,(%rax) 7736 0x0000000000404fff: .byte 0x0 7737 0x0000000000405000: Cannot access memory at address 0x405000 Lastly, I'll note that I see a lot of gdb.btrace failures without this commit. Worse still, the results aren't always the same which causes a lot of noise when comparing test results. gdbsupport/ChangeLog: * btrace-common.h (btrace_cpu_vendor): Add CV_AMD. gdb/ChangeLog: * nat/linux-btrace.c (btrace_this_cpu): Add check for AMD processors. (cpu_supports_bts): Add CV_AMD case.
2020-05-14gdb: infrun: consume multiple events at each pass in stop_all_threadsLaurent Morichetti2-132/+142
[Simon: I send this patch on behalf of Laurent Morichetti, I added the commit message and performance measurement stuff. Also, this patch is better viewed with "git show -w".] stop_all_threads, in infrun.c, is used to stop all running threads on targets that are always non-stop. It's used, for example, when the program hits a breakpoint while GDB is set to "non-stop off". It sends a stop request for each running thread, then collects one wait event for each. Since new threads can spawn while we are stopping the threads, it's written in a way where it makes multiple such "send stop requests to running threads & collect wait events" passes. The function completes when it has made two passes where it hasn't seen any running threads. With the way it's written right now is, it iterates on the thread list, sending a stop request for each running thread. It then waits for a single event, after which it iterates through the thread list again. It sends stop requests for any running threads that's been created since the last iteration. It then consumes another single wait event. This makes it so we iterate on O(n^2) threads in total, where n is the number of threads. This patch changes the function to reduce it to O(n). This starts to have an impact when dealing with multiple thousands of threads (see numbers below). At each pass, we know the number of outstanding stop requests we have sent, for which we need to collect a stop event. We can therefore loop to collect this many stop events before proceeding to the next pass and iterate on the thread list again. To check the performance improvements with this patch, I made an x86/Linux program with a large number of idle threads (varying from 1000 to 10000). The program's main thread hits a breakpoint once all these threads have started, which causes stop_all_threads to be called to stop all these threads. I measured (by patching stop_all_threads): - the execution time of stop_all_threads - the total number of threads we iterate on during the complete execution of the function (the total number of times we execute the "for (thread_info *t : all_non_exited_threads ())" loop) These are the execution times, in milliseconds: # threads before after 1000 226 106 2000 997 919 3000 3461 2323 4000 4330 3570 5000 8642 6600 6000 9918 8039 7000 12662 10930 8000 16652 11222 9000 21561 15875 10000 26613 20019 Note that I very unscientifically executed each case only once. These are the number of loop executions: # threads before after 1000 1003002 3003 2000 4006002 6003 3000 9009002 9003 4000 16012002 12003 5000 25015002 15003 6000 36018002 18003 7000 49021002 21003 8000 64024002 24003 9000 81027002 27003 10000 100030002 30003 This last table shows pretty well the O(n^2) vs O(n) behaviors. Reg-tested on x86 GNU/Linux (Ubuntu 16.04). gdb/ChangeLog: YYYY-MM-DD Laurent Morichetti <Laurent.Morichetti@amd.com> YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com> * infrun.c (stop_all_threads): Collect multiple wait events at each pass.
2020-05-14gdb: remove TYPE_CODE macroSimon Marchi145-1746/+1744
Remove TYPE_CODE, changing all the call sites to use type::code directly. This is quite a big diff, but this was mostly done using sed and coccinelle. A few call sites were done by hand. gdb/ChangeLog: * gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use type::code instead.
2020-05-14gdb: add type::code / type::set_codeSimon Marchi12-52/+71
Add the code and set_code methods on code, in order to remove the TYPE_CODE macro. In this patch, the TYPE_CODE macro is changed to use type::code, so all the call sites that are used to set the type code are changed to use type::set_code. The next patch will remove TYPE_CODE completely. gdb/ChangeLog: * gdbtypes.h (struct type) <code, set_code>: New methods. (TYPE_CODE): Use type::code. Change all call sites used to set the code to use type::set_code instead.
2020-05-14[gdb/testsuite] Fix gdb.fortran/nested-funcs-2.exp with gdbserverTom de Vries2-1/+6
When running test-case gdb.fortran/nested-funcs-2.exp with target board native-gdbserver, we have: ... (gdb) call contains_keyword::subroutine_to_call()^M (gdb) FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: \ call contains_keyword::subroutine_to_call() ... This is caused by the fact that we're trying to match inferior output using gdb_test. Fix this by using gdb_test_stdio instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-14 Tom de Vries <tdevries@suse.de> * gdb.fortran/nested-funcs-2.exp: Use gdb_test_stdio to test inferior output.
2020-05-14[gdb/testsuite] Split up multi-exec test-casesTom de Vries18-105/+307
With test-case gdb.base/align.exp and target board native-gdbserver, we run into: ... (gdb) file outputs/gdb.base/align/c/align^M Reading symbols from outputs/gdb.base/align/c/align...^M (gdb) delete breakpoints^M (gdb) info breakpoints^M No breakpoints or watchpoints.^M (gdb) break main^M Breakpoint 1 at 0x4004ab: file outputs/gdb.base/align/c/align.c, line 838.^M (gdb) kill^M The program is not being run.^M (gdb) spawn gdbserver --once localhost:2592 outputs/gdb.base/align/align^M Process outputs/gdb.base/align/align created; pid = 6946^M Listening on port 2592^M target remote localhost:2592^M Remote debugging using localhost:2592^M warning: Mismatch between current exec-file outputs/gdb.base/align/c/align^M and automatically determined exec-file outputs/gdb.base/align/align^M exec-file-mismatch handling is currently "ask"^M Load new symbol table from "outputs/gdb.base/align/align"? (y or n) Quit^M (gdb) ERROR: test suppressed ... Fix this by turning this and similar test-cases into regular, single executable test-cases. This fixes 100+ FAILs with target board native-gdbserver. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-14 Tom de Vries <tdevries@suse.de> * gdb.base/align.exp: Split into ... * gdb.base/align.exp.in: ... * gdb.base/align-c++.exp: ... * gdb.base/align-c.exp: ... these. * gdb.base/infcall-nested-structs.exp: Split into ... * gdb.base/infcall-nested-structs.exp.in: ... * gdb.base/infcall-nested-structs-c++.exp: ... * gdb.base/infcall-nested-structs-c.exp: ... these. * gdb.base/info-types.exp: Split into ... * gdb.base/info-types.exp.in: ... * gdb.base/info-types-c++.exp: ... * gdb.base/info-types-c.exp: ... these. * gdb.base/max-depth.exp: Split into ... * gdb.base/max-depth.exp.in: ... * gdb.base/max-depth-c++.exp: ... * gdb.base/max-depth-c.exp: ... these. * gdb.cp/infcall-nodebug.exp: Split into ... * gdb.cp/infcall-nodebug.exp.in: ... * gdb.cp/infcall-nodebug-c++-d0.exp: ... * gdb.cp/infcall-nodebug-c++-d1.exp: ... * gdb.cp/infcall-nodebug-c-d0.exp: ... * gdb.cp/infcall-nodebug-c-d1.exp: ... these.
2020-05-14gdb/infrun: handle already-exited threads when attempting to stopTankut Baris Aktemur9-26/+432
In stop_all_threads, GDB sends signals to other threads in an attempt to stop them. While in a typical scenario the expected wait status is TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted to stop has already terminated. If so, a waitstatus other than TARGET_WAITKIND_STOPPED would be received. Handle this case appropriately. If a wait status that denotes thread termination is ignored, GDB goes into an infinite loop in stop_all_threads. E.g.: $ gdb ./a.out (gdb) start ... (gdb) add-inferior -exec ./a.out ... (gdb) inferior 2 ... (gdb) start ... (gdb) set schedule-multiple on (gdb) set debug infrun 2 (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 10449) infrun: clear_proceed_status_thread (process 10453) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 10449 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 10453 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 10449.10449.0 [process 10449], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 10449) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 10453 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 10453.10453.0 [process 10453], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 10453 infrun: process 10453 executing, already stopping infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = no-resumed infrun: infrun_async(0) infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping infrun: stop_all_threads status->kind = no-resumed process -1 infrun: process 10453 executing, already stopping ... And this polling goes on forever. This patch prevents the infinite looping behavior. For the same scenario above, we obtain the following behavior: ... (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31229) infrun: clear_proceed_status_thread (process 31233) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31229 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e infrun: infrun_async(1) infrun: prepare_to_wait infrun: proceed: resuming process 31233 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e infrun: prepare_to_wait infrun: Found 2 inferiors, starting at #0 infrun: target_wait (-1.0.0, status) = infrun: 31229.31229.0 [process 31229], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 1 (process 31229) exited normally] infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 31233 executing, need stop infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: stop_all_threads status->kind = exited, status = 0 process 31233 infrun: saving status status->kind = exited, status = 0 for 31233.31233.0 infrun: process 31233 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 31233 not executing infrun: stop_all_threads done (gdb) The exit event from Inferior 1 is received and shown to the user. The exit event from Inferior 2 is not displayed, but kept pending. (gdb) info inferiors Num Description Connection Executable * 1 <null> a.out 2 process 31233 1 (native) a.out (gdb) inferior 2 [Switching to inferior 2 [process 31233] (a.out)] [Switching to thread 2.1 (process 31233)] Couldn't get registers: No such process. (gdb) continue Continuing. infrun: clear_proceed_status_thread (process 31233) infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 31233 infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0). infrun: prepare_to_wait infrun: Using pending wait status status->kind = exited, status = 0 for process 31233. infrun: target_wait (-1.0.0, status) = infrun: 31233.31233.0 [process 31233], infrun: status->kind = exited, status = 0 infrun: handle_inferior_event status->kind = exited, status = 0 [Inferior 2 (process 31233) exited normally] infrun: stop_waiting (gdb) info inferiors Num Description Connection Executable 1 <null> a.out * 2 <null> a.out (gdb) When a process exits and we leave the process exit event pending, we need to make sure that at least one thread is left listed in the inferior's thread list. This is necessary in order to make sure we have a thread that we can later resume, so the process exit event can be collected/reported. When native debugging, the GNU/Linux back end already makes sure that the last LWP isn't deleted. When remote debugging against GNU/Linux GDBserver, the GNU/Linux GDBserver backend also makes sure that the last thread isn't deleted until the process exit event is reported to GDBserver core. However, between the backend reporting the process exit event to GDBserver core, and GDB consuming the event, GDB may update the thread list and find no thread left in the process. The process exit event will be pending somewhere in GDBserver's stop reply queue, or gdb/remote.c's queue, or whathever other event queue inbetween GDBserver and infrun.c's handle_inferior_event. This patch tweaks remote.c's target_update_thread_list implementation to avoid deleting the last thread of an inferior. In the past, this case of inferior-with-no-threads led to a special case at the bottom of handle_no_resumed, where it reads: /* Note however that we may find no resumed thread because the whole process exited meanwhile (thus updating the thread list results in an empty thread list). In this case we know we'll be getting a process exit event shortly. */ for (inferior *inf : all_non_exited_inferiors (ecs->target)) In current master, that code path is still reachable with the gdb.threads/continue-pending-after-query.exp testcase, when tested against GDBserver, with "maint set target-non-stop" forced "on". With this patch, the scenario that loop was concerned about is still properly handled, because the loop above it finds the process's last thread with "executing" set to true, and thus the handle_no_resumed function still returns true. Since GNU/Linux native and remote are the only targets that support non-stop mode, and with this patch, we always make sure the inferior has at least one thread, this patch also removes that "inferior with no threads" special case handling from handle_no_resumed. Since remote.c now has a special case where we treat a thread that has already exited as if it was still alive, we might need to tweak remote.c's target_thread_alive implementation to return true for that thread without querying the remote side (which would say "no, not alive"). After inspecting all the target_thread_alive calls in the codebase, it seems that only the one from prune_threads could result in that thread being accidentally deleted. There's only one call to prune_threads in GDB's common code, so this patch handles this by replacing the prune_threads call with a delete_exited_threads call. This seems like an improvement anyway, because we'll still be doing what the comment suggests we want to do, and, we avoid remote protocol traffic. Regression-tested on X86_64 Linux. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Tom de Vries <tdevries@suse.de> Pedro Alves <palves@redhat.com> PR threads/25478 * infrun.c (stop_all_threads): Do NOT ignore TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED, TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses received. (handle_no_resumed): Remove code handling a live inferior with no threads. * remote.c (has_single_non_exited_thread): New. (remote_target::update_thread_list): Do not delete a thread if is the last thread of the process. * thread.c (thread_select): Call delete_exited_threads instead of prune_threads. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Pedro Alves <palves@redhat.com> * gdb.multi/multi-exit.c: New file. * gdb.multi/multi-exit.exp: New file. * gdb.multi/multi-kill.c: New file. * gdb.multi/multi-kill.exp: New file.
2020-05-14gdb/infrun: enable/disable thread events of all targets in stop_all_threadsTankut Baris Aktemur5-7/+32
In stop_all_threads, the thread events of the current top target are enabled at the beginning of the function and then disabled at the end (at scope exit time). Because there may be multiple targets whose thread lists will be updated and whose threads are stopped, enable/disable thread events for all targets. This update caused a change in the annotations. In particular, a "frames-invalid" annotation is printed one more time due to switching the current inferior. Hence, gdb.base/annota1.exp and gdb.cp/annota2.exp tests are also updated. Regression-tested on X86_64 Linux using the default board file and the native-extended-gdbserver board file. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infrun.c (stop_all_threads): Enable/disable thread events of all targets. Move a debug message denoting the end of the function into the SCOPED_EXIT block. gdb/testsuite/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/annota1.exp: Update the expected output. * gdb.cp/annota2.exp: Ditto.
2020-05-14gdb: introduce 'all_non_exited_process_targets' and 'switch_to_target_no_thread'Tankut Baris Aktemur3-0/+43
Introduce two new convenience functions: 1. all_non_exited_process_targets: returns a collection of all process stratum targets that have non-exited inferiors on them. Useful for iterating targets. 2. switch_to_target_no_thread: switch the context to the first inferior of the given target, and to no selected thread. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * process-stratum-target.h: Include <set>. (all_non_exited_process_targets, switch_to_target_no_thread): New function declarations. * process-stratum-target.c (all_non_exited_process_targets) (switch_to_target_no_thread): New function implementations.
2020-05-14gdb/infrun: extract out a code piece into 'mark_non_executing_threads' functionTankut Baris Aktemur2-35/+48
This is a refactoring. The extracted function is placed deliberately before 'stop_all_threads' because the function will be re-used there in a subsequent patch for handling an exit status kind received from a thread that GDB attempted to stop. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infrun.c (handle_inferior_event): Extract out a piece of code into... (mark_non_executing_threads): ...this new function. Change-Id: I2b088f4a724f4260cb37068264964525cf62a118
2020-05-14gdb/infrun: move a 'regcache_read_pc' call down to first useTankut Baris Aktemur2-1/+7
In infrun.c's resume_1 function, move the definition of the local variable PC down to its first use. This is useful if the thread we want to resume is already gone with a pending exit event, because we avoid the error we would see otherwise when trying to read the PC. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * infrun.c (resume_1): Move a 'regcache_read_pc' call down to first use.
2020-05-14gdb: protect some 'regcache_read_pc' callsTankut Baris Aktemur3-3/+31
It possible that a thread whose PC we attempt to read is already dead. In this case, 'regcache_read_pc' errors out. This impacts the "proceed" execution flow, where GDB quits early before having a chance to check if there exists a pending event. To remedy, keep going with a 0 value for the PC if 'regcache_read_pc' fails. Because the value of PC before resuming a thread is mostly used for storing and checking the next time the thread stops, this tolerance is expected to be harmless for a dead thread/process. gdb/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * regcache.c (regcache_read_pc_protected): New function implementation that returns 0 if the PC cannot read via 'regcache_read_pc'. * infrun.c (proceed): Call 'regcache_read_pc_protected' instead of 'regcache_read_pc'. (keep_going_pass_signal): Ditto. gdbsupport/ChangeLog: 2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * common-regcache.h (regcache_read_pc_protected): New function declaration.
2020-05-13Remove ada-lang.c:align_valueTom Tromey2-14/+10
I recently noticed the align_value function in ada-lang.c. This can be removed, in favor of align_up from gdbsupport. gdb/ChangeLog 2020-05-13 Tom Tromey <tromey@adacore.com> * ada-lang.c (align_value): Remove. (ada_template_to_fixed_record_type_1): Use align_up.
2020-05-13gdb: update the copyright year in async-event.[ch]Tankut Baris Aktemur3-2/+7
The async-event.[ch] files were introduced recently as a result of splitting the event-loop. I believe the copyright year update was just an oversight. So, this patch fixes that. gdb/ChangeLog: 2020-05-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * async-event.c: Update the copyright year. * async-event.h: Update the copyright year.
2020-05-12gdb/testsuite: Disable path and duplicate checks when parallel testingAndrew Burgess2-0/+25
This commit disables the recently added checking for paths in test names, and for duplicate test names, when the gdb tests are run in parallel. When running the gdb tests in parallel the extra result count lines produced cause the dg-extract-results scripts to exit with an error. The patches for the dg-extract-results scripts have been posted to the gcc-patches mailing list here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545562.html Once they are merged there then these changes can be merged over to binutils-gdb, and this commit can be reverted. gdb/testsuite/ChangeLog: * lib/check-test-names.exp: Disable when testing is being run in parallel.
2020-05-12gdb: make two objfile functions return boolSimon Marchi3-12/+23
gdb/ChangeLog: * objfiles.h (is_addr_in_objfile, shared_objfile_contains_address_p): Return bool. * objfile.c (is_addr_in_objfile, shared_objfile_contains_address_p): Return bool.
2020-05-12[gdb/testsuite] Fix incorrect string concat in jit-elf.expTom de Vries2-2/+7
When running test-case gdb.base/jit-elf.exp with target board cc-with-gdb-index, we get: ... spawn -ignore SIGHUP gdb/contrib/cc-with-tweaks.sh -i gcc \ -fno-stack-protector src/gdb/testsuite/gdb.base/jit-elf-main.c \ -fdiagnostics-color=never -DATTACH=1 -DLOAD_ADDRESS=0x7000000 \ -DLOAD_INCREMENT=0x1000000 -g -lm \ -o outputs/gdb.base/jit-elf/jit-elf-main"-attach"^M outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \ No such file or directory.^M output is: outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \ No such file or directory.^M gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \ No such file or directory. UNTESTED: gdb.base/jit-elf.exp: failed to compile jit-elf-main"-attach" ... The problem is a string concat in jit-elf.exp: ... ${main_binfile}"-attach" ... which is intended to generate string 'jit-elf-main-attach' but instead generates string 'jit-elf-main"-attach"'. Fix this by using "${main_binfile}-attach" instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.base/jit-elf.exp: Fix string concat.
2020-05-12[gdb/testsuite] Fix tcl error in jit-elf-helpers.expTom de Vries2-8/+17
When running test-case jit-elf.exp with target board cc-with-gdb-index, I run into: ... gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \ No such file or directory. ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/jit-elf.exp. ERROR: can't read "main_basename": no such variable while executing "untested "failed to compile ${main_basename}.c"" (procedure "compile_jit_main" line 7) ... The problem is in compile_jit_main in lib/jit-elf-helpers.exp, where we try to emit an untested message using global variable main_basename.c. Fixing this by declaring the variable global results in duplicate test-names, because the same source file is compiled more than once. Instead, fix this by using the result name in the untested message. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * lib/jit-elf-helpers.exp: Don't use undefined variables in untested messages.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.multiTom de Vries2-4/+14
In gdb.multi we have: ... DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=run: inf2_how=run: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=run: inf2_how=attach: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=run: inf2_how=tty: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=attach: inf2_how=run: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=attach: inf2_how=attach: attach DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=attach: inf2_how=attach: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=attach: inf2_how=tty: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=tty: inf2_how=run: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=tty: inf2_how=attach: info inferiors DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=tty: inf2_how=tty: tty TTY DUPLICATE: gdb.multi/multi-term-settings.exp: \ inf1_how=tty: inf2_how=tty: info inferiors ... Fix these using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.multi/multi-term-settings.exp: Use with_test_prefix.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.adaTom de Vries4-16/+31
In gdb.ada we have these duplicate test-names: ... DUPLICATE: gdb.ada/catch_ex.exp: continuing to program completion DUPLICATE: gdb.ada/mi_catch_ex.exp: breakpoint at main DUPLICATE: gdb.ada/mi_catch_ex.exp: mi runto main DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: breakpoint at main DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: mi runto main ... Fix these using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.ada/catch_ex.exp: Use with_test_prefix. * gdb.ada/mi_catch_ex.exp: Same. * gdb.ada/mi_catch_ex_hand.exp: Same.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.fortranTom de Vries2-7/+19
In gdb.fortran we have: ... DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ DUPLICATE: gdb.fortran/complex.exp: whatis $ ... Fix this by using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.fortran/complex.exp: Use with_test_prefix.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.traceTom de Vries2-3/+7
In gdb.trace we have these duplicates: ... DUPLICATE: gdb.trace/passcount.exp: 4.20a: set all three passcounts to three DUPLICATE: gdb.trace/passcount.exp: 4.6: set passcount to zero DUPLICATE: gdb.trace/passcount.exp: 4.7: set passcount to large number (32767) ... Fix these by fixing the test-names. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.trace/passcount.exp: Fix test-names.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.pascalTom de Vries2-2/+10
In gdb.pascal we have these duplicates: ... DUPLICATE: gdb.pascal/gdb11492.exp: next DUPLICATE: gdb.pascal/gdb11492.exp: print char_array ... Fix these by using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.pascal/gdb11492.exp: Use with_test_prefix.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.{gdb,opt,xml}Tom de Vries4-7/+17
There are 3 test directories with one duplicate test-name: gdb.gdb, gdb.opt and gdb.xml. The duplicates are: ... DUPLICATE: gdb.gdb/complaints.exp: call complaint_internal ($cstr) DUPLICATE: gdb.opt/inline-locals.exp: info locals above bar 2 \ (PRMS: gdb/25695) DUPLICATE: gdb.xml/tdesc-regs.exp: ptype $extrareg ... Fix as appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.gdb/complaints.exp: Use with_test_prefix. * gdb.xml/tdesc-regs.exp: Same. * gdb.opt/inline-locals.exp: Fix test name.
2020-05-12[gdb/testsuite] add jit-elf-util.h and run jit functionMihails Strasuns2-39/+133
Splits ELF related symbols into a separate jit-elf-util.h header and enhances it with a few more. Intention is to make adding new JIT tests possible without repeating most of the common boilerplate. As a test enhancement, jit-elf-main.c now calls the renamed function after registering the jit object and ensures it returns an expected result. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * gdb.base/jit-elf-util.h: New header file. * gdb.base/jit-elf-main.c: Use jit-elf-util.h, add a call to the renamed JIT function to verify its result.
2020-05-12[gdb/testsuite] define jit function name via macroMihails Strasuns3-34/+8
Replaces previous approach with patching resulting ELF binary after loading - now that each test iteration works on a separately compiled binary it is not necessary anymore. Tests are still being ran without debug info to preserve original test functionality but this change opens up the possibility to enable debug info if needed too. gdb/testsuite/ChangeLog: 2020-03-27 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: Supply -DFUNCTION_NAME macro definition when compiling jit-elf-solib.co. * gdb.base/jit-elf-main.c: Stop patching jit function name. * gdb.base/jit-elf-solib.c: Use FUNCTION_NAME macro value as a function name.
2020-05-12[gdb/testsuite] use -Ttext-segment for jit-elf testsMihails Strasuns2-15/+46
Removes the need to manually relocate loaded ELF binary by using a fixed constant as both mmap base address and as a requested first segment address supplied to the linker. In future will enable JIT tests with a valid DWARF debug info. Current tests still need to compile without a debug info though, because they do a function name modification. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: Supply -Ttext-segment linker flag and define LOAD_ADDRESS/LOAD_INCREMENT macros for the compiled binaries. * gdb.base/jit-elf-main.c: Use LOAD_ADDRESS/LOAD_INCREMENT to calculate the mmap address.
2020-05-12[gdb/testsuite] add lib/jit-elf-helpers.expMihails Strasuns3-106/+93
New utility library to be used by jit-elf tests responsible for compiling binary artifacts. In the next commit the compilation process will become more complicated because of extra mandatory flag - keeping it in one place will make tests less fragile. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * lib/jit-elf-helpers.exp: New file. * gdb.base/jit-elf.exp: Updated to use jit-elf-helpers.exp. * gdb.base/jit-elf-so.exp: Updated to use jit-elf-helpers.exp.
2020-05-12[gdb/testsuite] use args as lib list for jit-elf testsMihails Strasuns via Gdb-patches3-142/+252
Old usage: jit-elf-main lib.so 2 New usage: jit-elf-main lib.so.1 lib.so.2 Refactoring necessary to support running tests over multiple jit binaries rather than mapping the same binary muultiple times. gdb/testsuite/ChangeLog: 2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com> * gdb.base/jit-elf-main.c: Read lib list from argc/argv. * gdb.base/jit-elf.exp: Compile N jit libraries and use the list. * gdb.base/jit-elf-so.exp: Ditto.
2020-05-12[gdb/testsuite] Fix duplicate test-names in gdb.dwarf2Tom de Vries6-22/+38
We currently have these duplicate test-names in gdb.dwarf2: ... $ grep ^DUPLICATE: gdb.sum DUPLICATE: gdb.dwarf2/comp-unit-lang.exp: show language DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (void *)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/data-loc.exp: ptype foo.array_type DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (int)" DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (void *)" DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=off: \ set print object off DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=on: \ set print object on DUPLICATE: gdb.dwarf2/dw2-bad-parameter-type.exp: ptype f ... Fix as appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-12 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/comp-unit-lang.exp: Use with_test_prefix. * gdb.dwarf2/dw2-bad-parameter-type.exp: Same. * gdb.dwarf2/implref-struct.exp: Same. * gdb.dwarf2/varval.exp: Ensure get_sizeof is called once per type. * gdb.dwarf2/data-loc.exp: Same. Remove duplicate test.
2020-05-11gdb: change duplicate test name in gdb.base/jit-so.expSimon Marchi2-1/+6
When running gdb.base/jit-so.exp, we see duplicate test names: $ grep PASS testsuite/gdb.sum | sort | uniq -c | sort -n ... 2 PASS: gdb.base/jit-so.exp: one_jit_test-1: info function jit_function 2 PASS: gdb.base/jit-so.exp: one_jit_test-2: info function jit_function Give an explicit name to one test to avoid this. gdb/testsuite/ChangeLog: * gdb.base/jit-so.exp (one_jit_test): Change test name.
2020-05-11Restore info_command and breakpointTom Tromey3-2/+28
As discussed on gdb-patches, this restores info_command and the breakpoint on info_command in gdb-gdb.gdb. This reverts a tiny part of 0743fc83c03 ("Replace most calls to help_list and cmd_show_list"), as well as 652fc23a30a ("Remove gdb-gdb.gdb breakpoint on disappeared function info_command."). gdb/ChangeLog 2020-05-11 Tom Tromey <tromey@adacore.com> * cli/cli-cmds.c (info_command): Restore. (_initialize_cli_cmds): Use add_prefix_command for "info". * gdb-gdb.gdb.in: Restore breakpoint on info_command.
2020-05-11gdb/testsuite: Detect and warn about duplicate test namesAndrew Burgess2-6/+48
Building on the previous commit, this patch detects when two tests have the same test name and causes Dejagnu to print a new result type '# of duplicate test names' in the result summary. A line starting with 'DUPLICATE: ' is also added to the gdb.sum and gdb.log files. The DUPLICATE markers will be printed the second time a duplicate test name is seen, and every time after that. So you might see: PASS: gdb.base/sometest.exp: foo PASS: gdb.base/sometest.exp: bar PASS: gdb.base/sometest.exp: foo DUPLICATE: gdb.base/sometest.exp: foo PASS: gdb.base/sometest.exp: baz PASS: gdb.base/sometest.exp: foo DUPLICATE: gdb.base/sometest.exp: foo However, the results will report a duplicate count of 1, indicating that just one test name (foo) was duplicated. Currently if the tests are run in parallel mode the new result type is not merged into the combined summary file so users will need to run in non-parallel mode to check this result. Similarly, the 'DUPLICATE: ' markers will not be merged into the final gdb.sum file. A later commit will fix this. gdb/testsuite/ChangeLog: * lib/check-test-names.exp (all_test_names): New module variable. (counts): Add 'duplicates' field. (_check_duplicates): New procedure. (check): Also check for duplicates. (do_log_summary): Print duplicates count. (do_reset_vars): Reset counter for duplicate test names, and discard all know test names.
2020-05-11gdb/testsuite: Detect and warn if paths are used in test namesAndrew Burgess3-0/+148
A new library is introduced that hooks into the core of Dejagnu and detects when a test's name includes either the source or build paths. If any offending test names are detected then Dejagnu will print a new result type, '# of paths in test names'. Users should treat this result type just like other bad results types, and aim not to increase this number. As well as displaying the total number of offending tests as part of the final results, a new marker is included in both the gdb.log and gdb.sum files, this marker starts with 'PATH: ', so an offending test would be expected to appear like this: PASS: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe PATH: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe This should make it easier to track down offending tests. Currently for a local run on my machine, I don't see any offending test names, but it is possible that different targets, or different configurations, might currently be breaking the no paths rule. In order to get this working I have needed to wrap two core Dejagnu functions, log_summary, and reset_vars. Relying on core functions that are not part of any API is always going to be risky, given the relatively slow rate of Dejagnu change this is probably OK for now, and we can possibly upstream some changes to Dejagnu that would allow this functionality to be supported in a more official way later on. Currently if the tests are run in parallel mode the new result type is not merged into the combined summary file so users will need to run in non-parallel mode to check this result. Similarly, the 'PATH: ' markers will not be merged into the combined summary file. A later commit will fix this. gdb/testsuite/ChangeLog: * lib/gdb.exp: Include check-test-names.exp library. * lib/check-test-names.exp: New file.
2020-05-11Fix Ada value printing on PPC64Tom Tromey4-5/+15
The val_print removal patches introduced an Ada regression on PPC64 (probably any big-endian system). The issue comes because value_field does not understand that Ada wrapper fields can be bitfields that wrap a non-scalar type. In this case the value is already left-justified, so the justification done there does the wrong thing. Perhaps it would be good, eventually, to change value_field to understand this case. In the meantime this implements an Ada-specific solution. gdb/ChangeLog 2020-05-11 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_value_primitive_field): Now public. * ada-lang.h (ada_value_primitive_field): Declare. * ada-valprint.c (print_field_values): Use ada_value_primitive_field for wrapper fields.
2020-05-11[gdb/testsuite] Change kfail into xfail in gdb.ada/packed_tagged.expTom de Vries2-2/+6
Test-case gdb.ada/packed_tagged.exp contains a kfail: ... setup_kfail "gnat compiler bug" *-*-* ... Kfails are used to indicate problems in gdb, xfails are used to indicate problems in the environment. A bug in the gnat compiler is a problem in the environment rather than gdb. Fix this by changing the kfail into an xfail. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> * gdb.ada/packed_tagged.exp: Change kfail into xfail.
2020-05-11Fix gdb.ada/attr_ref_and_charlit.exp typoKeith Seitz2-1/+5
... introduced by my last commit: -gdb_test "print s'last" " = 3" + gdb_test "print s'last" " = 3Z gdb/testsuite/ChangeLog 2020-05-11 Keith Seitz <keiths@redhat.com> * gdb.ada/attr_ref_and_charlit.exp: Fix typo.
2020-05-11[gdb/testsuite] Fix gdb.cp/cpexprs-debug-types.exp inclusionTom de Vries4-748/+772
When running tests using RUNTESTFLAGS="cpexprs.exp cpexprs-debug-types.exp", we have: ... Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ... Running src/gdb/testsuite/gdb.cp/cpexprs.exp ... ... In the first test-case, we have -fdebug-types-section as expected: ... Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ... g++ -fno-stack-protector -fdiagnostics-color=never \ -fdebug-types-section \ -c -g \ -o outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types0.o \ src/gdb/testsuite/gdb.cp/cpexprs.cc ... but in the second test-case, we have also have -fdebug-types-section: ... Running src/gdb/testsuite/gdb.cp/cpexprs.exp ... g++ -fno-stack-protector -fdiagnostics-color=never \ -fdebug-types-section \ -c -g -g \ -o outputs/gdb.cp/cpexprs/cpexprs0.o \ src/gdb/testsuite/gdb.cp/cpexprs.cc ... This is due to using a global variable flags, which is set in cpexprs-debug-types.exp and tested for existence in cpexprs.exp. Fix this by using a more robust inclusion mechanism, that is: - move the bulk of the test-case cpexprs.exp to cpexprs.exp.in, - include it from cpexprs.exp and cpexprs-debug-types.exp, and - set flags in both .exp files gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> * gdb.cp/cpexprs.exp: Move everything except flags setting ... * gdb.cp/cpexprs.exp.in: .. here. * gdb.cp/cpexprs-debug-types.exp: Include cpexprs.exp.in instead of cpexprs.exp.
2020-05-11Clean-up gdb.ada test namesKeith Seitz16-47/+86
This patch fixes all duplicate and tail parentheses test names. These can really hinder automated test analysis such as used by the buildbot. Before: $ cat testsuite/gdb.sum | egrep "^(PASS|FAIL|XPASS|XFAIL|KPASS|KFAIL)" \ | sort | uniq -c | sort -n | grep -v " 1 " 2 PASS: gdb.ada/attr_ref_and_charlit.exp: print s'last 2 PASS: gdb.ada/bp_on_var.exp: set breakpoint pending off 2 PASS: gdb.ada/complete.exp: complete p pck.inne 2 PASS: gdb.ada/fun_overload_menu.exp: multiple matches for f (f (1, null)) 2 PASS: gdb.ada/type_coercion.exp: p q 2 PASS: gdb.ada/unc_arr_ptr_in_var_rec.exp: print My_P_Object.Ptr when no longer null 3 PASS: gdb.ada/fun_overload_menu.exp: 1 After: <empty> For parentheses, I've audited all occurrences of trailing parentheses. Most offenders are of the form: gdb_test "p func (..)" $expected_result I've either added a unique test name or simply removed the whitespace between the function name and the argument list. gdb/testsuite/ChangeLog 2020-05-11 Keith Seitz <keiths@redhat.com> * gdb.ada/arrayparam.exp: Resolve duplicate and tail parentheses test names. * gdb.ada/arrayptr.exp: Likewise. * gdb.ada/assign_arr.exp: Likewise. * gdb.ada/attr_ref_and_charlit.exp: Likewise. * gdb.ada/bp_on_var.exp: Likewise. * gdb.ada/call_pn.exp: Likewise. * gdb.ada/complete.exp: Likewise. * gdb.ada/fun_overload_menu.exp: Likewise. * gdb.ada/funcall_param.exp: Likewise. * gdb.ada/funcall_ref.exp: Likewise. * gdb.ada/packed_array_assign.exp: Likewise. * gdb.ada/same_component_name.exp: Likewise. * gdb.ada/type_coercion.exp: Likewise. * gdb.ada/unc_arr_ptr_in_var_rec.exp: Likewise. * gdb.ada/variant_record_packed_array.exp: Likewise.
2020-05-11[gdb/symtab] Save modules in .debug_namesTom de Vries2-0/+7
When running test-case gdb.fortran/info-modules.exp with target board debug-names, I run into: ... FAIL: gdb.fortran/info-modules.exp: info modules: check for entry \ 'info-types-2.f90', '18', 'mod2' ... In more detail, comparing the behaviour of the executable without and with .debug_names section, we have: ... -$ gdb -batch info-modules -ex "info modules" +$ gdb -batch info-modules.debugnames -ex "info modules" All defined modules: -File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types-2.f90: -18: mod2 - File /data/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/info-types.f90: 16: mod1 ... This is due to the fact that the .debug_names section does not contain DW_TAG_module entries. Fix this in debug_names::psymbol_tag. Build and tested on x86_64-linux with target board debug-names. gdb/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> * dwarf2/index-write.c (debug_names::psymbol_tag): Handle MODULE_DOMAIN.
2020-05-11[gdb/symtab] Fix incomplete CU list assert in .debug_namesTom de Vries8-108/+260
Consider the following two-file test-case: ... $ cat main.c extern int foo (void); int main (void) { int sum, a, b; sum = a + b + foo (); return sum; } $ cat foo.c int foo (void) { return 3; } ... Compiled like this: ... $ clang-10 -gdwarf-5 -gpubnames -c main.c $ clang-10 -gdwarf-5 -c foo.c $ clang-10 -gdwarf-5 -gpubnames main.o foo.o ... When loading this exec into gdb, we run into this assert: ... $ gdb a.out Reading symbols from a.out... warning: Section .debug_aranges in a.out entry at offset 0 \ debug_info_offset 0 does not exists, ignoring .debug_aranges. src/gdb/dwarf2/read.c:6949: \ internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \ abbrev_table*, int, bool): \ Assertion `this_cu->length == cu->header.get_length ()' failed. ... The problem is that the determined length of the CU: ... (gdb) p /x this_cu->length $4 = 0x26a ... does not match the actual length: ... (gdb) p /x cu->header.get_length () $5 = 0x59 ... The length of the CU is determined in create_cus_from_debug_names_list, and set based on this list in the .debug_names section: ... Compilation Unit offsets [ CU[0]: 0x000000c7 ] ... and it is assumed that this is a complete list, so the size of the CU is calculated using the end of the .debug_section at 0x331, making it 0x331 - 0xc7 == 0x26a. However, the CU list is not complete: ... $ llvm-dwarfdump -debug-info a.out \ | grep "Compile Unit" \ | sed 's/Compile Unit.*//' 0x00000000: 0x0000002e: 0x000000a5: 0x000000c7: 0x00000120: 0x00000157: 0x0000030f: ... In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs is due to openSUSE having debug info for various linked in objects). Fix the assert by not assuming to know the length of CUs in create_cus_from_debug_names_list (if the .debug_names is not produced by GDB), and setting it to 0, and setting it later to the actual length. Note that this does not fix the .debug_aranges warning, that's PR25969. Build and tested on x86_64-linux, with native and debug-names. gdb/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> PR symtab/25941 * dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs with length 0, if not gdb-produced. (cutu_reader::cutu_reader): Set CU length to actual length if 0. gdb/testsuite/ChangeLog: 2020-05-11 Tom de Vries <tdevries@suse.de> PR symtab/25941 * gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored out of ... * gdb.dwarf2/clang-debug-names.exp: ... here. * gdb.dwarf2/clang-debug-names-2.exp: New file. Include clang-debug-names.exp.in. * gdb.dwarf2/clang-debug-names-2-foo.c: New test. * gdb.dwarf2/clang-debug-names-2.c: New test.
2020-05-11gdb/fortran: Allow Flang MAIN_ in Fortran testingAlok Kumar Sharma40-64/+145
Name of fortran main function for Flang compiler is MAIN_ while for gfortran it is MAIN__ . In test cases MAIN__ is hardcoded for the purpose of inserting breakpoint. New proc is added to detect main function name depending on the compiler used. Fortran specific version of runto_main named fortran_runto_main is added. This commit adds support for Flang main function, there should be no change for gfortran. gdb/testsuite/ChangeLog * lib/fortran.exp (fortran_main): New Proc, handle flang MAIN_, (fortran_runto_main): New Proc, fortran version of runto_main. * gdb.fortran/array-bounds-high.exp: Handle flang MAIN_. * gdb.fortran/array-bounds.exp: Likewise. * gdb.fortran/array-slices.exp: Likewise. * gdb.fortran/block-data.exp: Likewise. * gdb.fortran/charset.exp: Likewise. * gdb.fortran/common-block.exp: Likewise. * gdb.fortran/complex.exp: Likewise. * gdb.fortran/derived-type-function.exp: Likewise. * gdb.fortran/derived-type.exp: Likewise. * gdb.fortran/info-modules.exp: Likewise. * gdb.fortran/info-types.exp: Likewise. * gdb.fortran/intrinsics.exp: Likewise. * gdb.fortran/library-module.exp: Likewise. * gdb.fortran/logical.exp: Likewise. * gdb.fortran/max-depth.exp: Likewise. * gdb.fortran/module.exp: Likewise. * gdb.fortran/multi-dim.exp: Likewise. * gdb.fortran/nested-funcs.exp: Likewise. * gdb.fortran/print-formatted.exp: Likewise. * gdb.fortran/print_type.exp: Likewise. * gdb.fortran/printing-types.exp: Likewise. * gdb.fortran/ptr-indentation.exp: Likewise. * gdb.fortran/ptype-on-functions.exp: Likewise. * gdb.fortran/subarray.exp: Likewise. * gdb.fortran/vla-alloc-assoc.exp: Likewise. * gdb.fortran/vla-datatypes.exp: Likewise. * gdb.fortran/vla-history.exp: Likewise. * gdb.fortran/vla-ptr-info.exp: Likewise. * gdb.fortran/vla-ptype-sub.exp: Likewise. * gdb.fortran/vla-ptype.exp: Likewise. * gdb.fortran/vla-sizeof.exp: Likewise. * gdb.fortran/vla-type.exp: Likewise. * gdb.fortran/vla-value-sub-arbitrary.exp: Likewise. * gdb.fortran/vla-value-sub-finish.exp: Likewise. * gdb.fortran/vla-value-sub.exp: Likewise. * gdb.fortran/vla-value.exp: Likewise. * gdb.fortran/whatis_type.exp: Likewise. * gdb.mi/mi-var-child-f.exp: Likewise.
2020-05-09[gdb] Fix catch throw regexp matchingTom de Vries2-1/+7
When running test-case gdb.mi/mi-catch-cpp-exceptions.exp, we have: ... FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \ breakpoint in main (unknown output after running) ... This is a regression since commit 596dc4adff "Speed up psymbol reading by removing a copy". Before that commit, we have: ... $ gdb \ -batch \ ./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \ -ex "break 67" \ -ex "catch throw -r blahblah" \ -ex r Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67. Catchpoint 2 (throw) Breakpoint 1, main () at mi-catch-cpp-exceptions.cc:67 67 return 1; /* Stop here. */ ... In other words: - we set a breakpoint somewhere in main, - we set a catchpoint with a regexp that is intended to not match any exception, and - run to the breakpoint, without the catchpoint triggering. After the commit, we have: ... $ gdb \ -batch \ ./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \ -ex "break 67" \ -ex "catch throw -r blahblah" \ -ex r Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67. Catchpoint 2 (throw) Catchpoint 2 (exception thrown), 0x00007ffff7ab037e in __cxa_throw () from \ /usr/lib64/libstdc++.so.6 ... In other words, the catchpoint triggers. This is caused by this bit of the commit: ... type_name = cplus_typename_from_type_info (typeinfo_arg); canon = cp_canonicalize_string (type_name.c_str ()); - if (!canon.empty ()) - std::swap (type_name, canon); + name = (canon == nullptr + ? canon.get () + : type_name.c_str ()); } catch (const gdb_exception_error &e) { exception_print (gdb_stderr, e); } - if (!type_name.empty ()) + if (name != nullptr) { - if (self->pattern->exec (type_name.c_str (), 0, NULL, 0) != 0) + if (self->pattern->exec (name, 0, NULL, 0) != 0) ... Before the commit, we have: - type_name == "my_exception" - canon = "" and the !type_name.empty () test succeeds, and gdb executes the self->pattern->exec call. After the commit, we have: - type_name == "my_exception" - canon == NULL - name == NULL and the name != nullptr test fails, and gdb doesn't execute the self->pattern->exec call. Fix this by inverting the condition for the calculation of name: ... - name = (canon == nullptr + name = (canon != nullptr ... Build and tested on x86_64-linux. gdb/ChangeLog: 2020-05-09 Tom de Vries <tdevries@suse.de> PR gdb/25955 * break-catch-throw.c (check_status_exception_catchpoint): Fix name calculation.
2020-05-09Change server_command to boolTom Tromey3-2/+7
I noticed that "server_command" is an int, but really it should be a bool. gdb/ChangeLog 2020-05-09 Tom Tromey <tom@tromey.com> * top.c (server_command): Now bool. * top.h (server_command): Now bool.
2020-05-09Fix for the complaint observed when symbol reading due to unsupported ↵nitachra3-12/+23
.debug_names form Following complaint is observed with the executable compiled with -gdwarf-5 and -gpubnames flags - "During symbol reading: Unsupported .debug_names form DW_FORM_ref4". This is the form corresponding to DW_IDX_die_offset attribute. This patch fixes this complaint. Tested with clang 10.0.0. Test case used - int main() { int sum,a,b; sum = a + b; return sum; } clang -gdwarf-5 -gpubnames test.c -o test.out gdb -q test.out -ex "set complaints 1" -ex "start" Reading symbols from test.out... During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] Temporary breakpoint 1 at 0x400484 Starting program: test.out During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \ [in module test.out] gdb/dwarf2/ChangeLog: 2020-05-09 Nitika Achra <Nitika.Achra@amd.com> PR symtab/25952 * read.c (dw2_debug_names_iterator::next): Handle DW_FORM_ref* and DW_IDX_die_offset. If there is no compilation unit attribute in the index entry, then there is a single CU. Return the CU at O index of compilation unit vector. gdb/testsuite/ChangeLog: 2020-05-09 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/clang-debug-names.exp: Remove PR25952 kfail.
2020-05-08Don't re-process a DIE in read_lexical_block_scopeTom Tromey2-1/+15
A customer reported a crash in the DWARF reader. Investigation showed that the crash occurred in an unusual scenario: a function was lexically scoped within some other function -- but the inner function inlined the outer function and referred to its DIE via DW_AT_abstract_origin. With the executable in question, inherit_abstract_dies could eventually call read_lexical_block_scope, which in turn could recurse into process_die, to process a DIE that was already being read, triggering an assert. This came up once before; see: https://www.sourceware.org/ml/gdb-patches/2014-02/msg00652.html However, in this case, I don't have an easy way to reproduce. So, there is no test case. I did experiment with the failing executable. This patch fixes the bug and doesn't seem to cause other issues. For example, I can still set breakpoints on the relevant functions. gdb/ChangeLog 2020-05-08 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (read_lexical_block_scope): Don't process a DIE already being processed.
2020-05-08More C++-ification for struct displayTom Tromey2-126/+93
This changes displays to have a constructor, use bool and std::string, and to be stored using std::vector. The ALL_DISPLAYS and ALL_DISPLAYS_SAFE macros are removed. While internal iteration is still done via map_display_numbers, this is updated to use a function_view. These changes simplify the code somewhat; for example, free_display can now be removed in favor of ordinary destruction. gdb/ChangeLog 2020-05-08 Tom Tromey <tom@tromey.com> * printcmd.c (struct display) <next>: Remove. <display>: New constructor. <exp_string>: Now a std::string. <enabled_p>: Now a bool. (display_number): Move definition earlier. (displays): Rename from display_chain. Now a std::vector. (ALL_DISPLAYS, ALL_DISPLAYS_SAFE): Remove. (display_command): Update. (do_one_display, disable_display) (enable_disable_display_command, do_enable_disable_display): Update. (free_display): Remove. (clear_displays): Rewrite. (delete_display): Update. (map_display_numbers): Use function_view. Remove "data" parameter. Update. (do_delete_display): Remove. (undisplay_command): Update. (do_one_display, do_displays, disable_display) (info_display_command): Update. (do_enable_disable_display): Remove. (enable_disable_display_command) (clear_dangling_display_expressions): Update.
generated by cgit v1.1 at 2025-01-29 09:59:10 +0000