aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-04-01gdb/testing/tui: add new _csi_{L,S,T}Andrew Burgess2-0/+180
This patch was original part of this series: https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html I've pulled this out as it might be useful ahead of the bigger series being merged. This commit adds: _csi_L - insert line _csi_S - pan down _csi_T - pan up
2022-03-31x86: Remove bfd_arch_l1om and bfd_arch_k1omH.J. Lu14-243/+17
Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been removed from gas, ld and opcodes. bfd/ * Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo. (ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c. * archures.c (bfd_mach_l1om): Removed. (bfd_mach_l1om_intel_syntax): Likewise. (bfd_mach_k1om): Likewise. (bfd_mach_k1om_intel_syntax): Likewise. (bfd_k1om_arch): Likewise. (bfd_l1om_arch): Likewise. (bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch references. * config.bfd (targ_selvecs): Remove l1om_elf64_vec. l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec. (targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch. * configure.ac (k1om_elf64_vec): Removed. (k1om_elf64_fbsd_vec): Likewise. (l1om_elf64_vec): Likewise. (l1om_elf64_fbsd_vec): Likewise. * cpu-k1om.c: Removed. * cpu-l1om.c: Likewise. * elf64-x86-64.c (elf64_l1om_elf_object_p): Removed. (elf64_k1om_elf_object_p): Likewise. (l1om_elf64_vec): Removed. (l1om_elf64_fbsd_vec): Likewise. (k1om_elf64_vec): Likewise. (k1om_elf64_fbsd_vec): Likewise. (ELF_TARGET_OS): Undefine. * targets.c (_bfd_target_vector): Remove k1om_elf64_vec, k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec. * Makefile.in: Regenerate. * bfd-in2.h: Likewise. * configure: Likewise. opcodes/ * configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references. * disassemble.c (disassembler): Likewise. * configure: Regenerate.
2022-03-31gdb/ctf: pass partial symtab's filename to buildsym_compunitSimon Marchi1-1/+1
I noticed that the CTF symbol reader passes the objfile's name to all buildsym_compunit instances it creates. The result is that all compunit_symtabs created have the same name, that of the objfile: { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x621000286760) debugformat ctf producer (null) name libbabeltrace2.so.0.0.0 dirname (null) blockvector ((struct blockvector *) 0x6210003911d0) user ((struct compunit_symtab *) (null)) { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0) fullname (null) linetable ((struct linetable *) 0x0) } } { ((struct compunit_symtab *) 0x621000275c10) debugformat ctf producer (null) name libbabeltrace2.so.0.0.0 dirname (null) blockvector ((struct blockvector *) 0x621000286710) user ((struct compunit_symtab *) (null)) { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730) fullname (null) linetable ((struct linetable *) 0x0) } } Notice the two "name libbabeltrace2.so.0.0.0". Change it to pass the partial_symtab's filename instead. The output becomes: { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x621000295610) debugformat ctf producer (null) name libbabeltrace2.so.0.0.0 dirname (null) blockvector ((struct blockvector *) 0x6210003a15d0) user ((struct compunit_symtab *) (null)) { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0) fullname (null) linetable ((struct linetable *) 0x0) } } { ((struct compunit_symtab *) 0x621000288700) debugformat ctf producer (null) name current-thread.c dirname (null) blockvector ((struct blockvector *) 0x6210002955c0) user ((struct compunit_symtab *) (null)) { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0) fullname (null) linetable ((struct linetable *) 0x0) } } Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as its name. This is because the CTF symbol reader really creates a partial symtab named like this. It appears to be because the debug info contains information that has been factored out of all CUs and is at the "top-level" of the objfile, outside any real CU. So it creates a partial symtab and an artificial CU that's named after the objfile. Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
2022-03-31gdb: print compunit_symtab name in "maint info symtabs"Simon Marchi1-0/+1
I think it would make sense to print a compunit_symtab's name in "maint info symtabs". If you are looking for a given CU in the list, that's probably the field you will be looking at. As the doc of compunit_symtab::name says, it is not meant to be a reliable file name, it is for debugging purposes (and "maint info symtabs" exists for debugging purposes). Sample output with the new field: (gdb) maintenance info symtabs { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00) { ((struct compunit_symtab *) 0x621000131630) debugformat DWARF 5 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 name test.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000131d10) user ((struct compunit_symtab *) (null)) { symtab test.c ((struct symtab *) 0x6210001316b0) fullname (null) linetable ((struct linetable *) 0x621000131d40) } { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0) fullname (null) linetable ((struct linetable *) 0x0) } { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710) fullname (null) linetable ((struct linetable *) 0x0) } } { ((struct compunit_symtab *) 0x6210001170a0) debugformat DWARF 5 producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0 name foo.c dirname /home/simark/build/binutils-gdb-one-target/gdb blockvector ((struct blockvector *) 0x621000131580) user ((struct compunit_symtab *) (null)) { symtab foo.c ((struct symtab *) 0x621000117120) fullname (null) linetable ((struct linetable *) 0x6210001315b0) } { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150) fullname (null) linetable ((struct linetable *) 0x0) } } } Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
2022-03-31gdb/ctf: don't create a buildsym_compunit when building partial symbolsSimon Marchi1-19/+1
I am trying to do some changes to buildsym_compunit, so I am auditing the current uses. Something seems odd with this use of buildsym_compunit (that this patch removes). A buildsym_compunit is normally used when building a compunit_symtab. That is, when expanding a partial symtab into a full compunit symtab. In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which is only used when creating partial symtabs. At this moment, I don't see how that's useful. ctf_start_archive creates a new buildsym_compunit and starts a subfile. But that buildsym_compunit is never used again. It's just overriden in ctf_start_symtab, which means we leak the old buildsym_compunit, I suppose. Remove ctf_start_archive completely. Add an assert in ctf_start_symtab to verify that we are not overwriting an existing buildsym_compunit (meaning we'd leak the existing one). This assert triggers without the other part of the fix. When doing: $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ... (gdb) maintenance expand-symtabs /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed. Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
2022-03-31Style URLs in GDB outputTom Tromey6-15/+40
I noticed that GDB will display URLs in a few spots. This changes them to be styled. Originally I thought I'd introduce a new "url" style, but there aren't many places to use this, so I just reused filename styling instead. This patch also changes the debuginfod URL list to be printed one URL per line. I think this is probably a bit easier to read.
2022-04-01Automatic date update in version.inGDB Administrator1-1/+1
2022-03-31gdb: initialize ctf_context::builder in create_partial_symtabSimon Marchi1-0/+1
I built a random project with -gctf, in order to test the CTF support in GDB. With my ASan/UBSan/etc-enabled build of GDB, I get: $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ... Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0... /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment 0xbebebebebebebebe: note: pointer points here The 0xbebebebebebebebe value is a sign that the ctf_context::builder field is uninitialized. The problem probably goes under the radar if the field happens to be zero-initialized, because ctf_start_archive contains this code: if (ccx->builder == nullptr) { ccx->builder = new buildsym_compunit (of, of->original_name, nullptr, language_c, 0); If the field was zero-initialized (by chance), this will create a new buildsym_compunit. But if the field was purposely filled with random bytes by one of the sanitizers, we won't create a buildsym_compunit here and we'll continue with ccx->builder equal to 0xbebebebebebebebe. Fix this the easy way by initializing ccx->builder where the other ctf_context fields are initialized (yeah, this code could be made nicer C++, but I am going for the obvious fix here). With this patch, this passes cleanly on my system: $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc" # of expected passes 40 ... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my system gcc does not have it. Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
2022-03-31Remove dbx modeTom Tromey13-503/+24
This patch removes gdb's dbx mode. Regression tested on x86-64 Fedora 34.
2022-03-31gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xmlH.J. Lu8-38/+12
1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate them into a single keys.xml. 2. Enable PKU for x32 to fix: $ gdbserver :123456 x32-program ... .../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected . Unknown register pkru requested on Tiger Lake.
2022-03-31gdb/linux-nat: remove check based on current_inferior in ↵Simon Marchi4-13/+199
linux_handle_extended_wait The check removed by this patch, using current_inferior, looks wrong. When debugging multiple inferiors with the Linux native target and linux_handle_extended_wait is called, there's no guarantee about which is the current inferior. The vfork-done event we receive could be for any inferior. If the vfork-done event is for a non-current inferior, we end up wrongfully ignoring it. As a result, the core never processes a TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed is never cleared, and breakpoints are never reinserted. However, because the Linux native target decided to ignore the event, it resumed the thread - while breakpoints out. And that's bad. The proposed fix is to remove this check. Always report vfork-done events and let infrun's logic decide if it should be ignored. We don't save much cycles by filtering the event here. Add a test that replicates the situation described above. See comments in the test for more details. Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
2022-03-31gdbserver/linux: set lwp !stopped when failing to resumeSimon Marchi1-2/+18
I see some failures, at least in gdb.multi/multi-re-run.exp and gdb.threads/interrupted-hand-call.exp. Running `stress -C $(nproc)` at the same time as the test makes those tests relatively frequent. Let's take gdb.multi/multi-re-run.exp as an example. The failure looks like this, an unexpected "no resumed": continue Continuing. No unwaited-for children left. (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit The situation is: - Inferior 1 is stopped somewhere, it won't really play a role here. - Inferior 2 has 2 threads, both stopped. - We resume inferior 2, the leader thread is expected to exit, making the process exit. From GDB's perspective, a failing run looks like this: [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. [remote] wait: enter [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e; [remote] wait: exit [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: 713933.713933.0 [Thread 713933.713933], [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP [infrun] clear_step_over_info: clearing step over info [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0 [infrun] handle_signal_stop: stop_pc=0x555555555195 [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] process_event_stop_test: no stepping, continue [remote] Sending packet: $Z0,555555555194,1#8e [remote] Packet received: OK [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195 [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a [remote] Packet received: OK [remote] Sending packet: $vCont;c:pae4cd.-1#9f [infrun] prepare_to_wait: prepare_to_wait [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] fetch_inferior_event: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] do_target_wait: Found 2 inferiors, starting at #0 [infrun] random_pending_event_thread: None found. [remote] wait: enter [remote] Packet received: N [remote] wait: exit [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: -1.0.0 [process -1], [infrun] print_target_wait_results: status->kind = NO_RESUMED [infrun] handle_inferior_event: status->kind = NO_RESUMED [remote] Sending packet: $Hgp0.0#ad [remote] Packet received: OK [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n [infrun] stop_waiting: stop_waiting [remote] Sending packet: $qXfer:threads:read::0,1000#92 [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n [infrun] infrun_async: enable=0 [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote [infrun] fetch_inferior_event: exit We can see that we resume the inferior with vCont;c, but got NO_RESUMED. When the test passes, we get an EXITED status to indicate the process has exited. From GDBserver's point of view, it looks like this. The logs contain some logging I added and that are part of this patch. [remote] getpkt: getpkt ("vCont;c:pae4cf.-1"); [no ack sent] [threads] resume: enter [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped [threads] get_pc: pc is 0x555555555195 [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195 [threads] get_pc: pc is 0x7ffff7d35a95 [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95 [threads] resume: Resuming, no pending status or step over needed [threads] resume_one_thread: resuming LWP 713935 [threads] proceed_one_lwp: lwp 713935 [threads] resume_one_lwp_throw: continue from pc 0x555555555195 [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected) [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0 [threads] resume_one_thread: resuming LWP 713936 [threads] proceed_one_lwp: lwp 713936 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected) [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) [threads] resume: exit [threads] wait_1: enter [threads] wait_1: [<all threads>] [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected) [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0 [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1 [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd). [threads] delete_lwp: deleting 713935 [threads] wait_for_event_filtered: exit (no unwaited-for LWP) sigchld_handler [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED [threads] wait_1: exit What happens is: - We resume the leader (713935) successfully. - The leader exits. - We resume the secondary thread (713936), we get ESRCH. This is expected this the leader has exited. - resume_one_lwp_throw throws, it's caught by resume_one_lwp. - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the failure can be explained by the LWP becoming zombie, and swallows the error. - Note that this means that the secondary lwp still has stopped==1. - wait_1 is called, probably because linux_process_target::resume marks the async pipe at the end. - The exit event isn't ready yet, probably because the machine is under load, so waitpid returns nothing. - check_zombie_leaders detects that the leader is zombie and deletes - We try to find a resumed (non-stopped) LWP to get an event from, there's none since the leader (that was resumed) is now deleted, and the secondary thread is still marked stopped. wait_for_event_filtered returns -1, causing wait_1 to return NO_RESUMED. What I notice here is that there is some kind of race between the availability of the process' exit notification and the call to wait_1 that results from marking the async pipe at the end of resume. I think what we want from this wait_1 invocation is to keep waiting, as we will eventually get thread exit notifications for both of our threads. The fix I came up with is to mark the secondary thread as !stopped (or resumed) when we fail to resume it. This makes wait_1 see that there is at least one resume lwp, so it won't return NO_RESUMED. I think this makes sense to consider it resumed, because we are going to receive an exit event for it. Here's the GDBserver logs with the fix applied: [threads] resume: enter [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped [threads] get_pc: pc is 0x555555555195 [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195 [threads] get_pc: pc is 0x7ffff7d35a95 [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95 [threads] resume: Resuming, no pending status or step over needed [threads] resume_one_thread: resuming LWP 724597 [threads] proceed_one_lwp: lwp 724597 [threads] resume_one_lwp_throw: continue from pc 0x555555555195 [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected) [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0 [threads] resume_one_thread: resuming LWP 724598 [threads] proceed_one_lwp: lwp 724598 [threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95 [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected) [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process) [threads] resume: exit [threads] wait_1: enter [threads] wait_1: [<all threads>] sigchld_handler [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0 [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1 [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd). [threads] delete_lwp: deleting 724597 [threads] wait_for_event_filtered: sigsuspend'ing sigchld_handler [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited) [threads] filter_event: 724598 exited [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited) [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK sigchld_handler [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0 [threads] wait_1: exit Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
2022-03-31gdb/testsuite/tui: implement _csi_P procSimon Marchi2-0/+56
Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these errors when running gdb.tui/scroll.exp: ERROR: invalid command name "_csi_P" while executing "::gdb_tcl_unknown _csi_P 2" ("uplevel" body line 1) invoked from within "uplevel 1 ::gdb_tcl_unknown $args" (procedure "::unknown" line 5) invoked from within "_csi_P 2" ("eval" body line 1) invoked from within "eval _csi_$cmd $params" It looks like GDB is emitting a CSI that it did not emit before, the "Delete character" one: https://vt100.net/docs/vt510-rm/DCH.html Implement it. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
2022-03-31gdb: fix use of fprintf_filtered in top.cSimon Marchi1-2/+2
A race condition in how patches were pushed causes this build failure: CXX top.o /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’: /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’? 1622 | fprintf_filtered (stream, _("\ | ^~~~~~~~~~~~~~~~ fprintf_filtered has been removed, gdb_printf must be used now. Fix this. Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b
2022-03-31aarch64: Relax check for RNG system registersRichard Sandiford3-1/+14
FEAT_RNG is an optional Armv8.5-A extension, but it can be backported to earlier architectures as well. GAS previously made the RNG registers conditional on having both armv8.5-a and +rng, but only +rng should be required. This seems to be the only feature that was handled like this. opcodes/ * aarch64-opc.c (SR_RNG): Don't require V8_5. gas/ * testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New test.
2022-03-31* gdb/top.c (print_gdb_configuration): Announce --enable-threading.Eli Zaretskii1-0/+10
This includes the reporting of --enable/disable-threading as part of the GDB configuration description.
2022-03-31gdb/infrun: add reason parameter to stop_all_threadsSimon Marchi4-11/+14
Add a "reason" parameter, only used to show in debug messages what is the reason for stopping all threads. This helped me understand the debug logs while adding some new uses of stop_all_threads, so I am proposing to merge it. Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55
2022-03-31gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*Simon Marchi2-2/+2
I forgot to do this before pushing the previous commit. Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805
2022-03-31gdb: test vfork + follow-fork-mode=parent + detach-on-fork=offSimon Marchi2-0/+112
The particular behavior we have when using that combination of settings doesn't seem tested at all (at least, I don't find it if I grep for "Can not resume the parent process"). Add a simple test for that. Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5
2022-03-31Accept the + character as part of filenames for MRI scripts.Nick Clifton2-1/+5
2022-03-31Fix procfs.c compilationRainer Orth1-0/+1
procfs.c doesn't compile on Solaris: /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’: /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope 3302 | gdb_argv built_argv (args); | ^~~~~~~~ /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’? 3303 | for (char *arg : built_argv) | ^~~~~~~~~~ | buildargv Fixed by including "gdbsupport/buildargv.h". Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
2022-03-31Automatic date update in version.inGDB Administrator1-1/+1
2022-03-30gdb/testsuite: add tests for TermSimon Marchi2-25/+665
While trying to review Andrew's patch here [1], I thought I spotted a bug in the handling of a CSI, but I had no way to know for sure. So I thought it would be useful to have unit tests for the handling of control characters and control sequences of our toy terminal implementation. It might help avoid chasing bugs in the GDB TUI when in reality it's a problem with the testsuite's terminal implementation. Add the gdb.tui/tuiterm.exp file to do that. All currently supported control sequences and characters are tested, except _csi_m (the one that handles colors and stuff). _csi_m should probably be tested too, but it will require more work. Fix a few issues that the tests spotted: - backspace: according to [3] (table 4-1), a backspace when the cursor is at the beginning of a line should have no effect. Our implementation did wrap to the end of the previous line. Change our implementation to match the doc (and the test). - insert character: this control sequence is supposed to insert blank characters, shifting all the rest of the line right. The current implementation moves N characters right, but it overwrites the characters on the right instead of shifting them. It also doesn't insert blank characters at the cursor. - Cursor down, forward, next line: off-by-one error when reaching the end of the display. - erase in display, line: off-by-one errors. - vertical line position absolute: allowed setting the cursor outside the display, when it should clamp it to the display size. I found that this web page [2] gave some good clues on the expected behavior of some control characters or sequences that some other pages didn't. [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html [2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences [3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3 Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
2022-03-30Only allow QUIT on the main threadTom Tromey3-0/+28
Pedro pointed out that gdb worker threads should not react to quits. While I don't think that the new DWARF reader can call QUIT from a worker thread (and I don't think the existing minsym threading code can either), it seems safest to address this before checking in the new code. This patch arranges for the QUIT macro to only work on the main thread.
2022-03-30Use gdb_printf and gdb_vprintf in more placesTom Tromey2-14/+13
Luis pointed out that I missed a spot in the gdb_printf conversion -- namely aarch64-nat.c. While looking at this, I found another spot in darwin-nat.c that I also missed. I can't build either of these, but I think this patch should fix the problems.
2022-03-30Consolidate definition of current_directoryTom Tromey5-11/+7
I noticed that both gdbserver and gdb define current_directory. However, as it is referenced by gdbsupport, it seemed better to define it there as well. This patch also moves the declaration to pathstuff.h. Tested by rebuilding.
2022-03-30Decode "dynamic" interface types in AdaTom Tromey5-13/+165
In Ada, if a class implements an interface and has a dynamic superclass, then the "offset to top" -- the offset that says how to turn a pointer to the interface into a pointer to the whole object -- is stored in the object itself. This patch changes GDB to understand this. Because this only touches Ada code, and because Joel already reviewed it internally, I am checking it in.
2022-03-29Fix for MUL instruction on the v850Jeff Law2-2/+17
* sim/v850/simops.c (Multiply64): Properly test if we need to negate either of the operands. * sim/testsuite/v850/mul.cgs: New test.
2022-03-30Automatic date update in version.inGDB Administrator1-1/+1
2022-03-29Remove two unused hooksTom Tromey2-10/+0
I noticed that a couple of deprecated hooks aren't ever called, so they can't really be used by Insight. This patch removes them entirely. I checked the Insight sources, and these aren't mentioned there, either.
2022-03-29Remove unnecessary calls to wrap_here and gdb_flushTom Tromey7-21/+3
Various spots in gdb currently know about the wrap buffer, and so are careful to call wrap_here to be certain that all output has been flushed. Now that the pager is just an ordinary stream, this isn't needed, and a simple call to gdb_flush is enough. Similarly, there are places where gdb prints to gdb_stderr, but first flushes gdb_stdout. stderr_file already flushes gdb_stdout, so these aren't needed.
2022-03-29Minor comment updates in utils.hTom Tromey1-19/+13
This patch updates some comments in utils.h to more closely reflect the new reality.
2022-03-29Remove vfprintf_styledTom Tromey2-17/+0
Nothing calls vfprintf_styled any more, so remove it.
2022-03-29Remove ui_out_flag::unfiltered_outputTom Tromey2-24/+6
There is no longer any need for ui_out_flag::unfiltered_output -- nothing ever sets this flag. This used to be needed to make the _unfiltered output work, but now only printf_unfiltered can be used, and it uses the puts_unfiltered method. This patch removes the flag and the dead code.
2022-03-29Rename fprintf_symbol_filteredTom Tromey6-21/+21
fprintf_symbol_filtered is misnamed, because whether filtering happens is now up to the stream. This renames it to fprintf_symbol, which isn't a great name (the first "f" doesn't mean much and the second one is truly meaningless here), but "print_symbol" was already taken.
2022-03-29Rename puts_filtered_tabularTom Tromey3-10/+9
puts_filtered_tabular is now misnamed, because whether filtering happens is now up to the stream. So, rename it. (This function is pretty weird, and should probably be rewritten to avoid using the chars_printed global, and moved into objc-lang.c. However, I haven't done so.)
2022-03-29Rename print_spaces_filteredTom Tromey17-47/+47
print_spaces_filtered is now misnamed, because whether filtering happens is up to the stream. So, rename it.
2022-03-29Unify gdb printf functionsTom Tromey249-8470/+8456
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-29Unify gdb putc functionsTom Tromey26-78/+62
Now that filtered and unfiltered output can be treated identically, we can unify the putc family of functions. This is done under the name "gdb_putc". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey86-1204/+1196
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-03-29Unify vprintf functionsTom Tromey15-72/+30
Now that filtered and unfiltered output can be treated identically, we can unify the vprintf family of functions: vprintf_filtered, vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For the gdb_stdout variants, recall that only printf_unfiltered gets truly unfiltered output at this point.) This removes one such function and renames the remaining two to "gdb_vprintf". All callers are updated. Much of this patch was written by script.
2022-03-29Remove fputs_styled_unfilteredTom Tromey3-21/+10
fputs_styled_unfiltered is only called from cli_ui_out, so remove it. This area will be further simplified in future patches.
2022-03-29Change the pager to a ui_fileTom Tromey10-192/+230
This rewrites the output pager as a ui_file implementation. A new header is introduced to declare the pager class. The implementation remains in utils.c for the time being, because there are some static globals there that must be used by this code. (This could be cleaned up at some future date.) I went through all the text output in gdb to ensure that this change should be ok. There are a few cases: * Any existing call to printf_unfiltered is required to be avoid the pager. This is ensured directly in the implementation. * All remaining calls to the f*_unfiltered functions -- the ones that take an explicit ui_file -- either send to an unfiltered stream (e.g., gdb_stderr), which is obviously ok; or conditionally send to gdb_stdout I investigated all such calls by searching for: grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr This yields a number of candidates to check. * The breakpoint _print_recreate family, and save_trace_state_variables. These are used for "save" commands and so are fine. * Things printing to a temporary stream. Obviously ok. * Disassembly selftests. * print_gdb_help - this is non-obvious, but ok because paging isn't yet enabled at this point during startup. * serial.c - doens't use gdb_stdout * The code in compile/. This is all printing to a file. * DWARF DIE dumping - doesn't reference gdb_stdout. * Calls to the _filtered form -- these are all clearly ok, because if they are using gdb_stdout, then filtering will still apply; and if not, then filtering never applied and still will not. Therefore, at this point, there is no longer any distinction between all the other _filtered and _unfiltered calls, and they can be unified. In this patch, take special note of the vfprintf_maybe_filtered and ui_file::vprintf change. This is one instance of the above idea, erasing the distinction between filtered and unfiltered -- in this part of the change, the "unfiltered_output" flag is never passe to cli_ui_out. Subsequent patches will go much further in this direction. Also note the can_emit_style_escape changes in ui-file.c. Checking against gdb_stdout or gdb_stderr was always a bit of a hack; and now it is no longer needed, because this is decision can be more fully delegated to the particular ui_file implementation. ui_file::can_page is removed, because this patch removed the only call to it. I think this is the main part of fixing PR cli/7234. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7234
2022-03-29Remove vfprintf_styled_no_gdbfmtTom Tromey3-28/+8
This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point of call.
2022-03-29Add style-escape methods to ui_fileTom Tromey2-0/+43
This adds emit_style_escape and reset_style methods to ui_file. These aren't used yet, but they will be once the pager is converted to be a ui_file subclass.
2022-03-29Add puts_unfiltered method to ui_fileTom Tromey2-1/+17
When the pager is rewritten as a ui_file, gdb will still need a way to bypass the filtering. After examining a few approaches, I chose this patch, which adds a puts_unfiltered method to ui_file. For most implementations of ui_file, this will just delegate to puts. This patch also switches printf_unfiltered to use the new method.
2022-03-29Only have one API for unfiltered outputTom Tromey4-27/+3
At the end of this series, the use of unfiltered output will be very restricted -- only places that definitely need it will use it. To this end, I thought it would be good to reduce the number of _unfiltered APIs that are exposed. This patch changes gdb so that only printf_unfiltered exists. (After this patch, the f* variants still exist as well, but those will be removed later.)
2022-03-29Remove some uses of printf_unfilteredTom Tromey16-74/+74
A number of spots call printf_unfiltered only because they are in code that should not be interrupted by the pager. However, I believe these cases are all handled by infrun's blanket ban on paging, and so can be converted to the default (_filtered) API. After this patch, I think all the remaining _unfiltered calls are ones that really ought to be. A few -- namely in complete_command -- could be replaced by a scoped assignment to pagination_enabled, but for the remainder, the code seems simple enough like this.
2022-03-29Use unfiltered output in annotate.cTom Tromey1-74/+74
It seems to me that annotations should not be filtered. While it might be weird for an annotation-based UI to use the pager, it's not, I think, out of the question. This patch makes this change.
2022-03-29gdb/remote: use current_inferior in read_ptid if multi-process not supportedTankut Baris Aktemur3-4/+127
When parsing the ptid out of a reply package, if the multi-process extensions are not supported, use current_inferior's pid as the pid of the reported thread, instead of inferior_ptid. This is needed because the inferior_ptid may be null_ptid although a legit context exists, due to a prior context switch via switch_to_inferior_no_thread. Below is a scenario that illustrates what could go wrong. First, setup a multi-target scenario. This is needed, because in a multi-target setting, the inferior_ptid is cleared out before waiting on targets. The second inferior below sits on top of a remote target. Multi-process packets are disabled. $ # First, spawn a process with PID 26253 to attach to later. $ gdb-up a.out Reading symbols from a.out... (gdb) maint set target-non-stop on (gdb) set remote multiprocess-feature-packet off (gdb) start ... (gdb) add-inferior -no-connection [New inferior 2] Added inferior 2 (gdb) inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] (gdb) target extended-remote | gdbserver --multi - Remote debugging using | gdbserver --multi - Remote debugging using stdio (gdb) attach 26253 Attaching to Remote target Attached; pid = 26253 [New Thread 26253] [New inferior 3] Reading /tmp/a.out from remote target... ... [New Thread 26253] ... Reading /usr/local/lib/debug/....debug from remote target... >>> GDB seems to hang here. After attaching to a process and reading some library files, GDB seems to hang. One interesting thing to note is that [New Thread 26253] appears twice. We also see [New inferior 3] Running the same scenario with "debug infrun on" reveals more details. ... (gdb) attach 26253 [infrun] scoped_disable_commit_resumed: reason=attaching Attaching to Remote target Attached; pid = 26253 [New Thread 26253] [infrun] infrun_async: enable=1 [infrun] attach_command: immediately after attach: [infrun] attach_command: thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING [infrun] clear_proceed_status_thread: 26253.26253.0 [infrun] reset: reason=attaching [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote [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 [Thread 0], status) = [infrun] print_target_wait_results: 26253.26253.0 [Thread 26253], [infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_0 [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0 [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] context_switch: Switching context from 0.0.0 to 26253.26253.0 [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151 [infrun] stop_waiting: stop_waiting [infrun] stop_all_threads: starting [infrun] stop_all_threads: pass=0, iterations=0 [New inferior 3] Reading /tmp/a.out from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /tmp/a.out from remote target... Reading symbols from target:/tmp/a.out... [New Thread 26253] [infrun] stop_all_threads: 4723.4723.0 not executing [infrun] stop_all_threads: 26253.26253.0 not executing [infrun] stop_all_threads: 42000.26253.0 executing, need stop [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) = [infrun] print_target_wait_results: -1.0.0 [Thread 0], [infrun] print_target_wait_results: status->kind = IGNORE [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) = [infrun] print_target_wait_results: -1.0.0 [Thread 0], [infrun] print_target_wait_results: status->kind = IGNORE GDB tried to stop Thread 42000.26253.0, which does not exist, and we are waiting for a stop event that will never happen. The PID in '42000.26253.0', namely 42000, is the PID of magic_null_ptid. It comes from gdb/remote.c:read_ptid: /* Since the stub is not sending a process id, then default to what's in inferior_ptid, unless it's null at this point. If so, then since there's no way to know the pid of the reported threads, use the magic number. */ if (inferior_ptid == null_ptid) pid = magic_null_ptid.pid (); else pid = inferior_ptid.pid (); if (obuf) *obuf = pp; return ptid_t (pid, tid); Because multi-process was turned off, GDB did not parse an explicitly specified PID. Furthermore, inferior_ptid == null_ptid, and eventually GDB picked the PID from magic_null_ptid. If target-non-stop is not turned on at the beginning, the same bug reveals itself as a duplicated thread as shown below. # Same setup as above, without 'maint set target-non-stop on'. ... (gdb) attach 26253 Attaching to Remote target Attached; pid = 26253 [New inferior 3] ... [New Thread 26253] ... (gdb) info threads Id Target Id Frame 1.1 process 13517 "a.out" main () at test.c:3 * 2.1 Thread 26253 "a.out" 0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6 3.1 Thread 26253 "a.out" Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (gdb) Fix the problem by preferring current_inferior()'s pid instead of magic_null_ptid. Regression-tested on X86-64 Linux. Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
generated by cgit v1.1 at 2024-11-19 22:23:58 +0000