aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2022-04-29Move "catch load" to a new fileTom Tromey4-258/+311
The "catch load" code is reasonably self-contained, and so this patch moves it out of breakpoint.c and into a new file, break-catch-load.c. One function from breakpoint.c, print_solib_event, now has to be exposed, but this seems pretty reasonable.
2022-04-29De-duplicate .gdb_indexTom Tromey1-2/+23
This de-duplicates variables and types in .gdb_index, making the new index closer to what gdb generated before the new DWARF scanner series. Spot-checking the resulting index for gdb itself, it seems that the new scanner picks up some extra symbols not detected by the old one. I tested both the new and old versions of gdb on both new and old versions of the index, and startup time in all cases is roughly the same (it's worth noting that, for gdb itself, the index no longer provides any benefit over the DWARF scanner). So, I think this fixes the size issue with the new index writer. Regression tested on x86-64 Fedora 34.
2022-04-29Fix .debug_names regression with new indexerTom Tromey3-3/+85
At AdaCore, we run the internal gdb test suite in several modes, including one using the .debug_names index. This caught a regression caused by the new DWARF indexer. First, the psymtabs-based .debug_names generator was completely wrong. However, to avoid making the rewrite series even bigger (fixing the writer will also require rewriting the .debug_names reader), it attempted to preserve the weirdness. However, this was not done properly. For example the old writer did this: - case STRUCT_DOMAIN: - return DW_TAG_structure_type; The new code, instead, simply preserves the actual DWARF tag -- but this makes future lookups fail, because the .debug_names reader only looks for DW_TAG_structure_type. This patch attempts to revert to the old behavior in the writer.
2022-04-29gdb/infrun: make fetch_inferior_event restore thread if exited or signalledSimon Marchi1-3/+7
Commit 152a1749566 ("gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related test failures, such as: info inferiors^M Num Description Connection Executable ^M * 1 process 634972 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M 2 process 634975 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors inferior 2^M [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2 continue^M Continuing.^M [Inferior 2 (process 634975) exited normally]^M [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end break callee^M Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee What happens here is: - inferior 2 is selected - we continue, leading to inferior 2's exit - we set breakpoint, expect 2 locations, but only one location is resolved Reading between the lines, we understand that inferior 2 got pruned, when it shouldn't have been. The issue can be reproduced by hand with: $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun" ... Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14 14 int v = 5; [New inferior 2 (process 637627)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 17 if (pid == 0) /* set breakpoint here */ [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)] [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))] #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6 (gdb) continue Continuing. [infrun] clear_proceed_status_thread: 637627.637627.0 [infrun] proceed: enter [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT [infrun] scoped_disable_commit_resumed: reason=proceeding [infrun] start_step_over: enter [infrun] start_step_over: stealing global queue of threads to step, length = 0 [infrun] operator(): step-over queue now empty [infrun] start_step_over: exit [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: resuming 637627.637627.0 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7 [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0 [infrun] infrun_async: enable=1 [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop [infrun] reset: reason=proceeding [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] proceed: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] do_target_wait: Found 2 inferiors, starting at #1 [infrun] random_pending_event_thread: None found. [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: 637627.637627.0 [process 637627], [infrun] print_target_wait_results: status->kind = EXITED, exit_status = 0 [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0 [Inferior 2 (process 637627) exited normally] [infrun] stop_waiting: stop_waiting [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1 [infrun] stop_all_threads: pass=0, iterations=0 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: pass=1, iterations=1 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: done [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1 [Switching to Thread 0x7ffff7c9a740 (LWP 637624)] [infrun] infrun_async: enable=0 [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads (gdb) [infrun] fetch_inferior_event: exit (gdb) info inferiors Num Description Connection Executable * 1 process 637624 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork (gdb) i th Id Target Id Frame * 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17 After handling the EXITED event for inferior 2, inferior 2 should have stayed the current inferior, which should have prevented it from getting pruned. When debugging, we find that when getting at the prune_inferiors call, the current inferior is inferior 1. Further debugging shows that prior to the call to clean_up_just_stopped_threads_fsms, the current inferior is inferior 2, and after, it's inferior 1. Then, back in fetch_inferior_event, the restore_thread object is disabled, due to: /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the previously selected thread is gone. We have two choices - switch to no thread selected, or restore the previously selected thread (now exited). We chose the later, just because that's what GDB used to do. After this, "info threads" says "The current thread <Thread ID 2> has terminated." instead of "No thread selected.". */ if (!non_stop && cmd_done && ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED) restore_thread.dont_restore (); So in the end, inferior 1 stays current, and inferior 2 gets wrongfully pruned. I'd say clean_up_just_stopped_threads_fsms is the culprit here. It actually attempts to restore the event_thread to be current at the end, after the loop (I presume the current thread on entry is always supposed to be the event thread). But in this case, the event is of kind EXITED, and ecs->event_thread is not set, so the current inferior isn't restored. Fix that by using scoped_restore_current_thread. If there is no current thread, scoped_restore_current_thread will still restore the current inferior, and that's what we want. Random note: the thread_info object for inferior 2's thread is never freed. It is held (by refcount) by the restore_thread object in fetch_inferior_event, while the inferior's thread list gets cleared, in the exit event processing. When the refcount reaches 0 (when the restore_thread object is destroyed), there's nothing that actually deletes the thread_info object. And I think that nothing in GDB points to it anymore, so it leaks. I don't want to fix that in this patch, but thought it would be good to mention it, in case somebody has an idea for how to fix that. Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8
2022-04-29Slightly tweak and clarify target_resume's interfacePedro Alves4-62/+63
The current target_resume interface is a bit odd & non-intuitive. I've found myself explaining it a couple times the recent past, while reviewing patches that assumed STEP/SIGNAL always applied to the passed in PTID. It goes like this today: - if the passed in PTID is a thread, then the step/signal request is for that thread. - otherwise, if PTID is a wildcard (all threads or all threads of process), the step/signal request is for inferior_ptid, and PTID indicates which set of threads run free. Because GDB always switches the current thread to "leader" thread being resumed/stepped/signalled, we can simplify this a bit to: - step/signal are always for inferior_ptid. - PTID indicates the set of threads that run free. Still not ideal, but it's a minimal change and at least there are no special cases this way. That's what this patch does. It renames the PTID parameter to SCOPE_PTID, adds some assertions to target_resume, and tweaks target_resume's description. In addition, it also renames PTID to SCOPE_PTID in the remote and linux-nat targets, and simplifies their implementation a little bit. Other targets could do the same, but they don't have to. Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
2022-04-28Check OBJF_NOT_FILENAME in DWARF index codeTom Tromey2-6/+7
The DWARF index code currently uses 'stat' to see if an objfile represents a real file. However, I think it's more correct to check OBJF_NOT_FILENAME instead. Regression tested on x86-64 Fedora 34.
2022-04-28Remove "typedef enum ..."Tom Tromey14-38/+35
I noticed a few spots in GDB that use "typedef enum". However, in C++ this isn't as useful, as the tag is automatically entered as a typedef. This patch removes most uses of "typedef enum" -- the exceptions being in some nat-* code I can't compile, and glibc_thread_db.h, which I think is more or less a copy of some C code from elsewhere. Tested by rebuilding.
2022-04-28gdb: fix nullptr dereference in block::ranges()Andrew Burgess1-2/+12
This commit: commit f5cb8afdd297dd68273d98a10fbfd350dff918d8 Date: Sun Feb 6 22:27:53 2022 -0500 gdb: remove BLOCK_RANGES macro introduces a potential nullptr dereference in block::ranges, this is breaking most tests, e.g. gdb.base/break.exp is failing for me. In the above patch BLOCK_CONTIGUOUS_P is changed from this: #define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \ || BLOCK_NRANGES (bl) <= 1) to this: #define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \ || (bl)->ranges ().size () == 1) So, before the commit we checked for the block ranges being nullptr, but afterwards we just call block::ranges() in all cases. The problem is that block::ranges() looks like this: /* Return a view on this block's ranges. */ gdb::array_view<blockrange> ranges () { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } where m_ranges is: struct blockranges *m_ranges; And so, we see that the nullptr check has been lost, and we might end up dereferencing a nullptr. My proposed fix is to move the nullptr check into block::ranges, and return an explicit empty array_view if m_ranges is nullptr. After this, everything seems fine again.
2022-04-27gdb: remove BLOCKVECTOR_MAP macroSimon Marchi7-17/+26
Replace with equivalent methods. Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
2022-04-27gdb: constify addrmap_findSimon Marchi2-9/+9
addrmap_find shouldn't need to modify the addrmap, so constify the addrmap parameter. This helps for the following patch, where getting the map of a const blockvector will return a const addrmap. Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi25-161/+194
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi17-51/+56
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_CONTIGUOUS_P macroSimon Marchi3-9/+8
Replace with an equivalent method. Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
2022-04-27gdb: remove BLOCK_RANGE macroSimon Marchi1-5/+1
Replace with access through the block::ranges method. Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
2022-04-27gdb: remove BLOCK_NRANGES macroSimon Marchi3-19/+15
Replace with range for loops. Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
2022-04-27gdb: remove BLOCK_RANGES macroSimon Marchi3-17/+24
Replace with an equivalent method on struct block. Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
2022-04-27gdb: remove BLOCK_RANGE_{START,END} macrosSimon Marchi4-26/+35
Replace with equivalent methods on blockrange. Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
2022-04-27gdb: remove BLOCK_NAMESPACE macroSimon Marchi2-13/+19
Replace with equivalent methods. Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
2022-04-27gdb: remove BLOCK_MULTIDICT macroSimon Marchi7-30/+37
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi26-84/+92
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi24-69/+74
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi20-99/+117
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-27Make gdb.base/parse_number.exp test all architecturesPedro Alves1-11/+63
There are some subtle differences between architectures, like the size of a "long" type, and this isn't currently accounted for in gdb.base/parse_number.exp. For example, on aarch64 a long type is 8 bytes, whereas a long type is 4 bytes for x86_64. This causes the following FAIL's: FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff There are some fortran-specific divergences as well, where 32-bit architectures show "unsigned int" for both 32-bit and 64-bit integers and 64-bit architectures show "unsigned int" and "unsigned long" for 32-bit and 64-bit integers. There might be a bug that 32-bit fortran truncates 64-bit values to 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". Here's what we get for aarch64: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long (gdb) p sizeof (0xffffffff) $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long And for arm: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff quit type = unsigned long long (gdb) p sizeof (0xffffffff) quit $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long This patch... * Makes the testcase iterate over all architectures, thus covering all the different combinations of types/sizes every time. * Adjusts the expected values and types based on the sizes of long long, long and int. A particularly curious architecture is s12z, which has 32-bit long long, and thus no way to represent 64-bit integers in C-like languages. Co-Authored-By: Luis Machado <luis.machado@arm.com> Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
2022-04-27gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add ↵Christophe Lyon3-62/+267
unwind-secure-frames command This patch makes use of the support for several stack pointers introduced by the previous patch to switch between them as needed during unwinding. It introduces a new 'unwind-secure-frames' arm command to enable/disable mode switching during unwinding. It is enabled by default. It has been tested using an STM32L5 board (with cortex-m33) and the sample applications shipped with the STM32Cube development environment: GTZC_TZSC_MPCBB_TrustZone in STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC. The test consisted in setting breakpoints in various places and check that the backtrace is correct: SecureFault_Callback (Non-secure mode), __gnu_cmse_nonsecure_call (before and after the vpush instruction), SecureFault_Handler (Secure mode). This implies that we tested only some parts of this patch (only MSP* were used), but remaining parts seem reasonable. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Add support for multiple stack pointers on Cortex-MChristophe Lyon4-20/+284
Armv8-M architecture with Security extension features four stack pointers to handle Secure and Non-secure modes. This patch adds support to switch between them as needed during unwinding, and replaces all updates of cache->prev_sp with calls to arm_cache_set_prev_sp. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Introduce arm_cache_initChristophe Lyon1-6/+27
This patch is a preparation for the rest of the series and adds two arm_cache_init helper functions. It updates every place that updates cache->saved_regs to call the helper instead. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Define MSP and PSP registers for M-ProfileChristophe Lyon7-29/+89
This patch removes the hardcoded access to PSP in arm_m_exception_cache() and relies on the definition with the XML descriptions. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Fix prologue analysis to support vpushChristophe Lyon1-0/+29
While working on adding support for Non-secure/Secure modes unwinding, I noticed that the prologue analysis lacked support for vpush, which is used for instance in the CMSE stub routine. This patch updates thumb_analyze_prologue accordingly, adding support for vpush of D-registers. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.expEnze Li1-18/+48
Tom and Simon feedback that there is a test failing in this commit: commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6 Date: Sun Apr 17 15:09:46 2022 +0800 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I fixed the nit in this patch. The root of the problem is not correctly matching the presentation of internal breakpoints. In addition, as Pedro pointed out, the original testcase is not portable in some methods, so this patch fixes this issue and some other improvements. Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
2022-04-26gdb/testsuite: use with_cwd where possibleSimon Marchi8-67/+59
I learned about with_cwd today. I spotted a few spots that could use it, to make the code more robust. Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
2022-04-26GDB PowerPC record test cases for ISA 2.06 and ISA 3.1Carl Love4-0/+580
This patch adds PowerPC specific tests to verify recording of various instructions. The first test case checks the ISA 2.06 lxvd2x instruction. The second test case tests several of the ISA 3.01 instructions. Specifically, it checks the word and prefixed instructions and some of the Matrix Multiply Assist (MMA) instructions. The patch has been run on both Power 10 and Power 9 to verify the ISA 2.06 test case runs on both platforms without errors. The ISA 3.1 test runs without errors on Power 10 and is skipped as expected on Power 9.
2022-04-26Add recording support for the ISA 3.1 PowerPC instructions.Carl Love1-26/+1169
This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC gdb instruction recording routines. Case statement entries are added to a number of the existing routines for recording the 32-bit word instructions. A few new functions were added to handle the new word instructions. The 64-bit prefix instructions are all handled by a set of new routines. The function ppc_process_prefix_instruction() is the primary function to handle the prefixed instructions. It calls additional functions to handle specific sets of prefixed instructions. These new functions are: ppc_process_record_prefix_vsx_d_form(), ppc_process_record_prefix_store_vsx_ds_form(), ppc_process_record_prefix_op34(), ppc_process_record_prefix_op33(), ppc_process_record_prefix_op32(), ppc_process_record_prefix_store(), ppc_process_record_prefix_op59_XX3(), ppc_process_record_prefix_op42().
2022-04-26Handle encoding failures in Windows thread namesTom Tromey1-5/+16
Internally at AdaCore, we noticed that the new Windows thread name code could fail. First, it might return a zero-length string, but in gdb conventions it should return nullptr instead. Second, an encoding failure could wind up showing replacement characters to the user; this is confusing and not useful; it's better to recognize such errors and simply discard the name. This patch makes both of these changes.
2022-04-26bsd-kvm: Fix build after recent changes to path handling functions.John Baldwin1-13/+11
Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to std::string rather than simple char * pointers freed by xfree.
2022-04-26gdb: make some random Python files Python 3-compatibleSimon Marchi3-18/+18
I noticed that these files failed to format with Black, because they use print without parenthesis (which isn't Python 3 compatible). I don't know if these files are still relevant, but the change is trivial, so here it is. Change-Id: I116445c2b463486016f824d32effffc915b60766
2022-04-26PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp ↵Carl Love2-19/+20
and gdb.arch/vsx-regs.exp The format for printing the floating point values was changed by commit: commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e Author: Tom Tromey <tromey@adacore.com> Date: Thu Feb 17 13:43:59 2022 -0700 Change how "print/x" displays floating-point value Currently, "print/x" will display a floating-point value by first casting it to an integer type. This yields weird results like: (gdb) print/x 1.5 $1 = 0x1 ... Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242 The above change results in 417 regression test failures since the expected Power vector register output no longer match. This patch updates the expected Altivec floating point register prints to the hexadecimal format for both big endian and little endian systems. The patch also fixes a formatting isue with the decimal_vector expected value assign statements. The expected VSX vector_register1, vector_register1_vr, vector_register2, vector_register2_vr variables are updated to include the new float128 entry. Additionally, the comment in the vsx expect file about the initialization of the vs registers is updated. The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
2022-04-25Do not put linkage names into .gdb_indexTom Tromey1-0/+8
This changes the .gdb_index writer to skip linkage names. This was always done historically (though somewhat implicitly).
2022-04-25gdb/fortran: Support for assumed rank zerorupothar4-5/+27
If a variable is passed to function in FORTRAN as an argument the variable is treated as an array with rank zero. GDB currently does not support the case for assumed rank 0. This patch provides support for assumed rank 0 and updates the testcase as well. Without patch: Breakpoint 1, arank::sub1 (a=<error reading variable: failed to resolve dynamic array rank>) at assumedrank.f90:11 11 PRINT *, RANK(a) (gdb) p a failed to resolve dynamic array rank (gdb) p rank(a) failed to resolve dynamic array rank With patch: Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11 11 PRINT *, RANK(a) (gdb) p a $1 = 0 (gdb) p rank(a) $2 = 0
2022-04-25gdb/infrun: assert !step_over_info_valid_p in restart_threadsLancelot SIX1-1/+7
While working in gdb/infrun.c:restart_threads, I was wondering what are the preconditions to call the function. It seems to me that !step_over_info_valid_p should be a precondition (i.e. if we are doing an inline step over breakpoint, we do not want to resume non stepping threads as one of them might miss the breakpoint which is temporally disabled). To convince myself that this is true, I have added an assertion to enforce this, and got one regression in the testsuite: FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error) This call to restart_threads originates from handle_vfork_done which does not check if a step over is active when restarting other threads: if (target_is_non_stop_p ()) { scoped_restore_current_thread restore_thread; insert_breakpoints (); restart_threads (event_thread, event_thread->inf); start_step_over (); } In this patch, I propose to: - Call start_step_over before restart_threads. If a step over is already in progress (as it is the case in the failing testcase), start_step_over return immediately, and there is no point in restarting all threads just to stop them right away for a step over breakpoint. - Only call restart_threads if no step over is in progress at this point. In this patch, I also propose to keep the assertion in restart_threads to help enforce this precondition, and state it explicitly. I have also checked all other places which call restart_threads, and they all seem to check that there is no step over currently active before doing the call. As for infrun-related things, I am never completely sure I did not miss something. So as usual, all feedback and thoughts are very welcome. Tested on x86_64-linux-gnu. Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37
2022-04-24gdb: move setbuf calls out of gdb_readline_no_editing_callbackAndrew Burgess2-13/+39
After this commit: commit d08cbc5d3203118da5583296e49273cf82378042 Date: Wed Dec 22 12:57:44 2021 +0000 gdb: unbuffer all input streams when not using readline Issues were reported with some MS-Windows hosts, see the thread starting here: https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html Filed in bugzilla as: PR mi/29002 The problem seems to be that calling setbuf on terminal file handles is not always acceptable, see this mail for more details: https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html This commit does two things, first moving the setbuf calls out of gdb_readline_no_editing_callback so that we don't end up calling setbuf so often. Then, for MS-Windows hosts, we don't call setbuf for terminals, this appears to resolve the issues that have been reported. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
2022-04-22gdb: handle_no_resumed: only update thread list of event targetSimon Marchi1-6/+1
When running: $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver" I get: target remote localhost:2347^M Remote debugging using localhost:2347^M Reading symbols from /lib64/ld-linux-x86-64.so.2...^M Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M (gdb) continue^M Continuing.^M Cannot execute this command while the target is running.^M Use the "interrupt" command to stop the target^M and then try again.^M (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started The test does: - Connect to a remote target with inferior 2, continue and stop on the all_started function - Connect to a separate remote target / GDBserver instance with inferior 1, continue and (expect to) stop on the all_started function The failure seen above happens when trying to continue inferior 1. What happens is: - GDB tells inferior 1's remote target to continue - We go into fetch_inferior_event, try to get an event at random from the targets - do_target_wait happens to pick inferior 2's target - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense: inferior 2 is stopped, that target has no resumed thread - handle_no_resumed tries to update the thread list of all targets: for (auto *target : all_non_exited_process_targets ()) { switch_to_target_no_thread (target); update_thread_list (); } - When trying to update the thread list of inferior 1's target, it hits the "Cannot execute this command while the target is running" error. This target is working in "remote all-stop" mode, and it is currently waiting for a stop reply, so it can't send packets to update the thread list at this time. To handle the problem described in the comment in handle_no_resumed, I don't think it is necessary to update the thread list of all targets, but only the event target. That comment describes a kind of race condition where some target reports a breakpoint hit for a thread and then its last remaining resumed thread exits, so sends a "no resumed" event. If we ended up resuming the thread that hit a breakpoint, we want to ignore the "no resumed" and carry on. But I don't really see why we need to update the thread list on the other targets. I can't really articulate this, it's more a gut feeling, maybe I just fail to imagine the situation where this is needed. But here is the patch anyway, so we can discuss it. The patch changes handle_no_resumed to only update the thread list of the event target. This fixes the test run shown above. The way I originally tried to fix this was to make remote_target::update_thread_list return early if the target is currently awaiting a stop reply, since there's no way it can update the thread list at that time. But that felt more like papering over the problem. I then thought that we probably shouldn't be asking the target to update the thread list unnecessarily. Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58
2022-04-22gdb: handle bracketed-paste-mode and EOF correctlyAndrew Burgess3-12/+63
This commit replaces an earlier commit that worked around the issues reported in bug PR gdb/28833. The previous commit just implemented a work around in order to avoid the worst results of the bug, but was not a complete solution. The full solution was considered too risky to merge close to branching GDB 12. This improved fix has been applied after GDB 12 branched. See this thread for more details: https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html This commit replaces this earlier commit: commit 74a159a420d4b466cc81061c16d444568e36740c Date: Fri Mar 11 14:44:03 2022 +0000 gdb: work around prompt corruption caused by bracketed-paste-mode Please read that commit for a full description of the bug, and why is occurs. In this commit I extend GDB to use readline's rl_deprep_term_function hook to call a new function gdb_rl_deprep_term_function. From this new function we can now print the 'quit' message, this replaces the old printing of 'quit' in command_line_handler. Of course, we only print 'quit' in gdb_rl_deprep_term_function when we are handling EOF, but thanks to the previous commit (to readline) we now know when this is. There are two aspects of this commit that are worth further discussion, the first is in the new gdb_rl_deprep_term_function function. In here I have used a scoped_restore_tmpl to disable the readline global variable rl_eof_found. The reason for this is that, in rl_deprep_terminal, readline will print an extra '\n' character before printing the escape sequence to leave bracketed paste mode. You might then think that in the gdb_rl_deprep_term_function function, we could simply print "quit" and rely on rl_deprep_terminal to print the trailing '\n'. However, rl_deprep_terminal only prints the '\n' when bracketed paste mode is on. If the user has turned this feature off, no '\n' is printed. This means that in gdb_rl_deprep_term_function we need to print "quit" when bracketed paste mode is on, and "quit\n" when bracketed paste mode is off. We could absolutely do that, no problem, but given we know how rl_deprep_terminal is implemented, it's easier (I think) to just temporarily clear rl_eof_found, this prevents the '\n' being printed from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can now always print "quit\n" and this works for all cases. The second issue that should be discussed is backwards compatibility with older versions of readline. GDB can be built against the system readline, which might be older than the version contained within GDB's tree. If this is the case then the system readline might not contain the fixes needed to support correctly printing the 'quit' string. To handle this situation I have retained the existing code in command_line_handler for printing 'quit', however, this code is only used now if the version of readline we are using doesn't not include the required fixes. And so, if a user is using an older version of readline, and they have bracketed paste mode on, then they will see the 'quit' sting printed on the line below the prompt, like this: (gdb) quit I think this is the best we can do when someone builds GDB against an older version of readline. Using a newer version of readline, or the patched version of readline that is in-tree, will now give a result like this in all cases: (gdb) quit Which is what we want. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-04-22gdb: improved EOF handling when using readline 7Andrew Burgess2-2/+3
In this commit: commit a6b413d24ccc5d76179bab866834e11fd6fec294 Date: Fri Mar 11 14:44:03 2022 +0000 gdb: work around prompt corruption caused by bracketed-paste-mode a change was made to GDB to work around bug PR gdb/28833. The consequence of this work around is that, when bracketed paste mode is enabled in readline, and GDB is quit by sending EOF, then the output will look like this: (gdb) quit The ideal output, which is what we get when bracketed paste mode is off, is this: (gdb) quit The reason we need to make this change is explained in the original commit referenced above. What isn't mentioned in the above commit, is that the change that motivated this work around was only added in readline 8, older versions of readline don't require the change. In later commits in this series I will add a fix to GDB's in-tree copy of readline (this fix is back-ported from upstream readline), and then I will change GDB so that, when using the (patched) in-tree readline, we can have the ideal output in all cases. However, GDB can be built against the system readline. When this is done, and the system readline is version 8, then we will still have to use the work around (two line) style output. But, if GDB is built against the system readline, and the system readline is an older version 7 readline, then there's no reason why we can't have the ideal output, after all, readline 7 doesn't include the change that we need to work around. This commit changes GDB so that, when using readline 7 we get the ideal output in all cases. This change is trivial (a simple check against the readline version number) so I think this should be fine to include. For testing this commit, you need to configure GDB including the '--with-system-readline' flag, and build GDB on a system that uses readline 7, for example 'Ubuntu 18.04'. Then run the test 'gdb.base/eof-exit.exp', you should expect everything to PASS. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28833
2022-04-22gdb: prune inferiors at end of fetch_inferior_event, fix intermittent ↵Simon Marchi2-7/+43
failure of gdb.threads/fork-plus-threads.exp This test sometimes fail like this: info threads^M Id Target Id Frame ^M 11.12 process 2270719 Couldn't get registers: No such process.^M (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left [Inferior 11 (process 2270719) exited normally]^M info inferiors^M Num Description Connection Executable ^M * 1 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M 11 <null> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited) I can get it to fail quite reliably by pinning it to a core: $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp" The previous attempt at fixing this was: https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html What we see is part due to a possible unfortunate ordering of events given by the kernel, and what could be considered a bug in GDB. The test program makes a number of forks, waits them all, then exits. Most of the time, GDB will get and process the exit event for inferior 1 after the exit events of all the children. But this is not guaranteed. After the last child exits and is waited by the parent, the parent can exit quickly, such that GDB collects from the kernel the exit events for the parent and that child at the same time. It then chooses one event at random, which can be the event for the parent. This will result in the parent appearing to exit before its child. There's not much we can do about it, so I think we have to adjust the test to cope. After expect has seen the "exited normally" notification for inferior 1, it immediately does an "info thread" that it expects to come back empty. But at this point, GDB might not have processed inferior 11's (the last child) exit event, so it will look like there is still a thread. Of course that thread is dead, we just don't know it yet. But that makes the "no thread" test fail. If the test waited just a bit more for the "exited normally" notification for inferior 11, then the list of threads would be empty. So, first change, make the test collect all the "exited normally" notifications for all inferiors before proceeding, that should ensure we see an empty thread list. That would fix the first FAIL above. However, we would still have the second FAIL, as we expect inferior 11 to not be there, it should have been deleted automatically. Inferior 11 is normally deleted when prune_inferiors is called. That is called by normal_stop, which is only called by fetch_inferior_event only if the event thread completed an execution command FSM (thread_fsm). But the FSM for the continue command completed when inferior 1 exited. At that point inferior 11 was not prunable, as it still had a thread. When inferior 11 exits, prune_inferiors is not called. I think that can be considered a GDB bug. From the user point of view, there's no reason why in one case inferior 11 would be deleted and not in the other case. This patch makes the somewhat naive change to call prune_inferiors in fetch_inferior_event, so that it is called in this case. It is placed at this particular point in the function so that it is called after the user inferior / thread selection is restored. If it was called before that, inferior 11 wouldn't be pruned, because it would still be the current inferior. Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272
2022-04-22Un-break the coff-pe-read.c buildTom Tromey1-1/+1
This fixes a build breakage in my recent coff-pe-read.c change. I'm sorry about this. I don't understand how it happened, because I definitely built and tested the series on Windows, and I didn't change it before pushing. Something must have gone wrong on the Windows build, but I don't know what. I'll investigate and and re-test to be sure.
2022-04-22More const use and alloca avoidance in coff-pe-read.cTom Tromey1-13/+13
This changes another function in coff-pe-read.c to use 'const' more, and to avoid the use of alloca by instead using std::string.
2022-04-22Use std::string in coff-pe-read.cTom Tromey1-8/+5
coff-pe-read.c uses xsnprintf and alloca, but using std::string is better, and just as easy. In general I think alloca is something to be avoided, and unbounded uses especially so.
2022-04-22Remove a const-removing cast from coff-pe-read.cTom Tromey1-4/+3
coff-pe-read.c casts away const at one spot, but this is easily replaced by calling bfd_get_filename directly in a couple of debugging prints.
2022-04-22Simplify BFD section iteration in coff-pe-read.cTom Tromey1-42/+13
coff-pe-read.c iterates over BFD sections using bfd_map_over_sections, but it's much simpler to use a for-each loop. This allows for the removal of helper functions and types.
2022-04-22Fix method naming bug in new DWARF indexerTom Tromey3-2/+90
Pedro pointed out that gdb-add-index is much slower with the new DWARF indexer. He also noticed that, in some cases, the generated .gdb_index would have the wrong fully-qualified name for a method. I tracked this down to a bug in the indexer. If a type could have methods but was marked as a declaration, the indexer was ignoring it. However, this meant that the internal map to find the qualified name was not updated for this container.
generated by cgit v1.1 at 2025-09-20 19:16:08 +0000