aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-14Document pseudo-terminal and interrupting changesusers/palves/ctrl-cPedro Alves2-5/+135
This documents changes done in previous patches: - the fact that on GNU/Linux, GDB creates a pseudo-terminal for the inferior instead of juggling terminal settings. - That when the inferior and GDB share the terminal, you can't interrupt some programs with Ctrl-C. - That on GNU/Linux, you may get "Program stopped." instead of "Program received SIGINT" in response to Ctrl-C. - That run+detach may result in the program dying with SIGHUP. I was surprised that we do not currently have a node/section specifically to talk about interrupting programs. Thus I've added a new "Interrupting" section under the "Stopping and Continuing" chapter, with some xrefs to other sections. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * NEWS: Document pseudo-terminal, "tty /dev/tty" and Ctrl-C/SIGINT changes. Document "set/show debug managed-tty". gdb/doc/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.texinfo (Input/Output): Document that GDB may start a program associated with a pseudo-terminal. Document "tty /dev/tty". Document "set/show debug managed-tty". (Attach): Document what happens on run+detach on systems where GDB creates a pseudo-terminal for the inferior. (Stopping and Continuing): Add new Interrupting node. (Background Execution): Add anchor. (Features for Debugging MS Windows PE Executables): Add anchor. Change-Id: I267a0f9300c7ac4d2e7f14a9ba8eabc1eafcc5a7
2021-06-14GNU/Linux: Interrupt/Ctrl-C with SIGSTOP instead of SIGINT [PR gdb/9425, PR ↵Pedro Alves29-57/+315
gdb/14559] After the "Always put inferiors in their own terminal/session [gdb/9425, gdb/14559]" change, when a user types "Ctrl-C" while the inferior is running, GDB is the one who gets the SIGINT, not the inferior process. GDB then forwards the SIGINT to the inferior with target_pass_ctrlc. That was necessary but not not sufficient to fix PRs gdb/9425, gdb/14559, because if a program blocks SIGINT with e.g. sigprocmask, then if GDB sends it a SIGINT, the signal isn't ever delivered to the process, so ptrace does not intercept it. You type Ctrl-C, but nothing happens. Similarly, if a program uses sigwait to wait for SIGINT, and the program receives a SIGINT, the SIGINT is _not_ intercepted by ptrace, it goes straight to the inferior. Now that the Ctrl-C results in a SIGINT sent to GDB instead of the inferior, we can make GDB interrupt the program any other way we like. This patch makes non-stop-capable ports interrupt the program with stop_all_threads / target_stop (i.e., SIGSTOP) instead of target_pass_ctrlc (i.e., SIGINT), which always works -- SIGSTOP can't be blocked/ignored. (In the future GDB may even switch to PTRACE_INTERRUPT on Linux, though that's a project of its own.) Another advantage here is with multi-target -- currently, because GDB relies on Ctrl-C stopping one thread, and then stopping all other threads in reaction to that stop, target_pass_ctrlc tries to find one inferior with a thread that is running, in any target. If the selected target for some reason fails to process the Ctrl-C request, then the Ctrl-C ends up lost. The mechanism implemented in this patch is different -- we never have to pick a thread, inferior or target -- we're going to stop everything, so we end up in stop_all_threads. For non-stop, the patch preserves the current behavior of only stopping one thread in reaction to Ctrl-C, so it can still happen that the thread that GDB selects to stop disappears and the Ctrl-C ends up being lost. However, because now GDB always sees the SIGINT first, we can change how Ctrl-C behaves there too. We could even make it configurable -- for example, it could be reasonable that Ctrl-C simply drops the CLI back to the prompt, without stopping anything at all. That might be interesting for "set observer-mode on", at least. This commit has a user-visible behavior change in all-stop mode -- when you interrupt the program with Ctrl-C, instead of: Thread 1 "threads" received signal SIGINT, Interrupt. You'll get: Thread 1 "threads" stopped. Which is what you already got with the "interrupt" command in non-stop mode. If you really want to pass a SIGINT to the program, you can then issue: (gdb) signal SIGINT This commit also adjusts the testsuite to cope with that output alternative. With this change, the gdb.base/sigint-sigwait.exp and gdb.base/sigint-masked-out.exp testcases now pass cleanly on GNU/Linux, on both native debugging and gdbserver + "maint set target-non-stop on", so the kfails are adjusted accordingly. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * event-top.c (default_quit_handler): Mark infrun event-loop handler with mark_infrun_async_event_handler_ctrl_c instead of passing the Ctrl-C to the target directly with target_pass_ctrlc. * infcmd.c (interrupt_target_1): On non-stop targets, Mark infrun event-loop handler with mark_infrun_async_event_handler_interrupt_all instead of using target_interrupt. * infrun.c (interrupt_all_requested, switch_to_stop_thread) (sync_interrupt_all) (mark_infrun_async_event_handler_interrupt_all) (mark_infrun_async_event_handler_ctrl_c): New. (infrun_async_inferior_event_handler): Handle Ctrl-C/interrupt requests. * infrun.h (mark_infrun_async_event_handler_interrupt_all) (mark_infrun_async_event_handler_ctrl_c): Declare. * linux-nat.c (wait_for_signal): Don't handle Ctrl-C here. (linux_nat_wait_1): Handle it here, by marking the infrun event handler, and returning TARGET_WAITKIND_IGNORE with the quit flag still set. * target.c (maybe_pass_ctrlc): New. (target_terminal::inferior, target_terminal::restore_inferior): Use it. (target_pass_ctrlc): Ass there's no non-stop target pushed. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * gdb.base/bp-cmds-continue-ctrl-c.exp: Expect "stopped" in alternative to "signal SIGINT". * gdb.base/interrupt-daemon-attach.exp: Likewise. * gdb.base/interrupt-daemon.exp: Likewise. * gdb.base/interrupt-noterm.exp: Likewise. * gdb.base/interrupt.exp: Likewise. * gdb.base/random-signal.exp: Likewise. * gdb.base/range-stepping.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.mi/new-ui-mi-sync.exp: Likewise. * gdb.multi/multi-target-interrupt.exp: Likewise. * gdb.multi/multi-target-no-resumed.exp: Likewise. * gdb.multi/multi-term-settings.exp: Likewise. * gdb.server/reconnect-ctrl-c.exp: Likewise. * gdb.threads/async.exp: Likewise. * gdb.threads/continue-pending-status.exp: Likewise. * gdb.threads/leader-exit.exp: Likewise. * gdb.threads/manythreads.exp: Likewise. * gdb.threads/pthreads.exp: Likewise. * gdb.threads/schedlock.exp: Likewise. * gdb.threads/sigthread.exp: Likewise. * lib/gdb.exp (can_interrupt_blocked_sigint): New. * gdb.base/sigint-masked-out.exp (test_ctrl_c) (test_interrupt_cmd): Use can_interrupt_blocked_sigint, and don't kfail if true. * gdb.base/sigint-sigwait.exp (test_ctrl_c, test_interrupt_cmd): Likewise. Change-Id: I83c1b6a20deea1f1909156adde1d60b8f6f2629b
2021-06-14convert previous_inferior_ptid to strong reference to thread_infoPedro Alves4-7/+32
While working on a patch, I spotted a regression in the gdb.multi/multi-target-no-resumed.exp.exp testcase. Debugging the issue, I realized that the problem was related to how I was using previous_inferior_ptid to look up the thread the user had last selected. The problem is that previous_inferior_ptid alone doesn't tell you which target that ptid is from, and I was just always using the current target, which was incorrect. Two different targets may have threads with the same ptid. I decided to fix this by replacing previous_inferior_ptid with a strong reference to the thread, called previous_thread. A new update_previous_thread function is added can be used to updated previous_thread from inferior_ptid. This must be called in several places that really want to get rid of previous_thread thread, and reset the thread id counter, otherwise we get regressions like these: (gdb) info threads -gid Id GId Target Id Frame - * 1 1 Thread 2974541.2974541 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21 - (gdb) PASS: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid + * 1 2 Thread 2958361.2958361 "tids-gid-reset" main () at src/gdb/testsuite/gdb.multi/tids-gid-reset.c:21 + (gdb) FAIL: gdb.multi/tids-gid-reset.exp: single-inferior: after restart: info threads -gid and: Core was generated by `build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/si'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398 398 kill (getpid (), SIGABRT); +[Current thread is 1 (LWP 2662066)] Restored records from core file build/gdb/testsuite/outputs/gdb.reverse/sigall-precsave/sigall.precsave. #0 gen_ABRT () at src/gdb/testsuite/gdb.reverse/sigall-reverse.c:398 398 kill (getpid (), SIGABRT); continue Continuing. -Program received signal SIGABRT, Aborted. +Thread 1 received signal SIGABRT, Aborted. 0x00007ffff7dfd55b in kill () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. -(gdb) PASS: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT +(gdb) FAIL: gdb.reverse/sigall-precsave.exp: sig-test-1: get signal ABRT I.e., GDB was failing to restart the thread counter back to 1, because the previous_thread thread was being help due to the strong reference. Tested on GNU/Linux native, gdbserver and gdbserver + "maint set target-non-stop on". gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * infcmd.c (kill_command, detach_command, disconnect_command): Call update_previous_thread. * infrun.c (previous_inferior_ptid): Delete. (previous_thread): New. (update_previous_thread): New. (proceed, init_wait_for_inferior): Call update_previous_thread. (normal_stop): Adjust to compare previous_thread and inferior_thread. Call update_previous_thread. * infrun.h (update_previous_thread): Declare. * target.c (target_pre_inferior, target_preopen): Call update_previous_thread. Change-Id: I4f06dd81f00848bb7d6d26a94ff091e2a4e646d9
2021-06-14exists_non_stop_target: Avoid flushing framesPedro Alves2-3/+11
A following patch adds an exists_non_stop_target call in the target_terminal routines, and that surprisingly caused a weird regression / GDB crash: $ make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS="gdb.base/signest.exp" ... configuring for gdbserver local testing (extended-remote) Using src/gdb/testsuite/config/extended-gdbserver.exp as tool-and-target-specific interface file. Running src/gdb/testsuite/gdb.base/signest.exp ... ERROR: GDB process no longer exists Debugging the core, we see infinite recursion: (top-gdb) bt 20 #0 0x0000561d6a1bfeff in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #1 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #2 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #3 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #4 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #5 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #6 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #7 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #8 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #9 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #10 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #11 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #12 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #13 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #14 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #15 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #16 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #17 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #18 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #19 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 (More stack frames follow...) (top-gdb) bt -30 #157054 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #157055 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #157056 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #157057 0x0000561d6a1bfeb8 in get_frame_arch (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:2939 #157058 0x0000561d6a1b989f in frame_unwind_find_by_frame (this_frame=0x561d6b19f9c0, this_cache=0x561d6b19f9d8) at src/gdb/frame-unwind.c:174 #157059 0x0000561d6a1bff04 in frame_unwind_arch (next_frame=0x561d6b19f9c0) at src/gdb/frame.c:2950 #157060 0x0000561d6a1bbc65 in frame_unwind_pc (this_frame=0x561d6b19f9c0) at src/gdb/frame.c:970 #157061 0x0000561d6a1bf54c in get_frame_pc (frame=0x561d6b19fa90) at src/gdb/frame.c:2625 #157062 0x0000561d6a1bf63e in get_frame_address_in_block (this_frame=0x561d6b19fa90) at src/gdb/frame.c:2655 #157063 0x0000561d6a0cae7f in dwarf2_frame_cache (this_frame=0x561d6b19fa90, this_cache=0x561d6b19faa8) at src/gdb/dwarf2/frame.c:1010 #157064 0x0000561d6a0cb928 in dwarf2_frame_this_id (this_frame=0x561d6b19fa90, this_cache=0x561d6b19faa8, this_id=0x561d6b19faf0) at src/gdb/dwarf2/frame.c:1227 #157065 0x0000561d6a1baf72 in compute_frame_id (fi=0x561d6b19fa90) at src/gdb/frame.c:588 #157066 0x0000561d6a1bb16e in get_frame_id (fi=0x561d6b19fa90) at src/gdb/frame.c:636 #157067 0x0000561d6a1bb224 in get_stack_frame_id (next_frame=0x561d6b19fa90) at src/gdb/frame.c:650 #157068 0x0000561d6a26ecd0 in insert_hp_step_resume_breakpoint_at_frame (return_frame=0x561d6b19fa90) at src/gdb/infrun.c:7809 #157069 0x0000561d6a26b88a in handle_signal_stop (ecs=0x7ffc67022830) at src/gdb/infrun.c:6428 #157070 0x0000561d6a269d81 in handle_inferior_event (ecs=0x7ffc67022830) at src/gdb/infrun.c:5741 #157071 0x0000561d6a265bd0 in fetch_inferior_event () at src/gdb/infrun.c:4120 #157072 0x0000561d6a244c24 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:41 #157073 0x0000561d6a435cc4 in remote_async_serial_handler (scb=0x561d6b4a8990, context=0x561d6b4a4c48) at src/gdb/remote.c:14403 #157074 0x0000561d6a460bc5 in run_async_handler_and_reschedule (scb=0x561d6b4a8990) at src/gdb/ser-base.c:138 #157075 0x0000561d6a460cae in fd_event (error=0, context=0x561d6b4a8990) at src/gdb/ser-base.c:189 #157076 0x0000561d6a76a191 in handle_file_event (file_ptr=0x561d6b233ae0, ready_mask=1) at src/gdbsupport/event-loop.cc:575 #157077 0x0000561d6a76a743 in gdb_wait_for_event (block=1) at src/gdbsupport/event-loop.cc:701 #157078 0x0000561d6a7694ee in gdb_do_one_event () at src/gdbsupport/event-loop.cc:237 #157079 0x0000561d6a2df16b in start_event_loop () at src/gdb/main.c:421 #157080 0x0000561d6a2df2b6 in captured_command_loop () at src/gdb/main.c:481 #157081 0x0000561d6a2e0d16 in captured_main (data=0x7ffc67022bd0) at src/gdb/main.c:1353 #157082 0x0000561d6a2e0da8 in gdb_main (args=0x7ffc67022bd0) at src/gdb/main.c:1370 #157083 0x0000561d69eb3d82 in main (argc=13, argv=0x7ffc67022cf8, envp=0x7ffc67022d68) at src/gdb/gdb.c:33 This was caused by exists_non_stop_target flushing the frame cache via scoped_restore_current_thread/switch_to_thread, while we're in the middle of unwinding. Fix this by making exists_non_stop_target only switch the inferior, like done in target_pass_ctrlc. The annota1.exp change is necessary because we'd get a regression otherwise: @@ -238,8 +238,6 @@ Continuing. \032\032breakpoints-invalid -\032\032frames-invalid - \032\032breakpoint 3 Breakpoint 3, @@ -276,7 +274,7 @@ printf.c \032\032pre-prompt (gdb) \032\032prompt -PASS: gdb.base/annota1.exp: continue to printf +FAIL: gdb.base/annota1.exp: continue to printf ... because this patch avoids flushing the frame cache that lead to that missing frames-invalid. We still need to match frames-invalid because against gdbserver + "maint set target non-stop on", some other code path flushes the frame cache resulting in the annotation being emitted anyway. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * target.c (exists_non_stop_target): Use scoped_restore_current_inferior and set_current_inferior instead of scoped_restore_current_thread / switch_to_inferior_no_thread. Change-Id: I8402483ee755e64e54d8b7c4a67c177557f569bd
2021-06-14Always put inferiors in their own terminal/session [gdb/9425, gdb/14559]Pedro Alves17-118/+987
Currently, on GNU/Linux, it is not possible to interrupt with Ctrl-C programs that block or ignore SIGINT, with e.g., sigprocmask or signal(SIGINT, SIG_IGN). You type Ctrl-C, but nothing happens. Similarly, if a program uses sigwait to wait for SIGINT, and the program receives a SIGINT, the SIGINT is _not_ intercepted by ptrace, it goes straight to the inferior. These problems have been known for years, and recorded in gdb/9425, gdb/14559. This is a consequence of how GDB implements interrupting programs with Ctrl-C -- when GDB spawns a new process, it makes the process use the same terminal as GDB, and then makes the process's process group be the foreground process group in GDB's terminal. This means that when the process is running in the foreground, after e.g. "continue", when the user types Ctrl-C, the kernel sends a SIGINT to the foreground process group, which is the inferior. GDB then intercepts the SIGINT via ptrace, the same way it intercepts any other signal, stops all the other threads of the inferior if in all-stop, and presents the "Program received SIGINT" stop to the user. This patch paves the way to address gdb/9425, gdb/14559, by turning Ctrl-C handling around such that the SIGINT always reaches GDB first, not the inferior. That is done by making GDB put inferiors in their own terminal/session created by GDB. I.e., GDB creates a pseudo-terminal master/slave pair, makes the inferior run with the slave as its terminal, and pumps output/input on the master end. Because the inferior is run with its own session/terminal, GDB is free to remain as the foreground process in its own terminal, which means that the Ctrl-C SIGINT always reaches GDB first, instead of reaching the inferior first, and then GDB reacting to the ptrace-intercepted SIGINT. Because GDB gets the SIGINT first, GDB is then free to handle it by interrupting the program any way it sees fit. A following patch will then make GDB interrupt the program with SIGSTOP instead of SIGINT, which always works even if the inferior blocks/ignores SIGINT -- SIGSTOP can't be ignored. (In the future GDB may even switch to PTRACE_INTERRUPT, though that's a project of its own.) Having the inferior in its own terminal also means that GDB is in control of when inferior output is flushed to the screen. When debugging with the CLI, this means that inferior output is now never interpersed with GDB's output in an unreadable fashion. This will also allow fixing the problem of inferior output really messing up the screen in the TUI, forcing users to Ctrl-L to refresh the screen. This patch does not address the TUI part, but it shouldn't be too hard -- I wrote a quick&dirty prototype patch doing that a few years back, so I know it works. Implementation wise, here's what is happening: - when GDB spawns an inferior, unless the user asked otherwise with "tty /dev/tty", GDB creates a pty pair, and makes the slave end the inferior's terminal. Note that starting an inferior on a given terminal already exists, given the "tty" command. GDB records the master and slave ends of the pty. - GDB registers that new terminal's master end on the event loop. When the master is written to, it means the inferior has written some output on its terminal. The event loop wakes up and GDB flushes the inferior output to its own terminal / to the screen. - When target_terminal state is switched to "inferior", with target_tarminal::inferiors(), GDB registers the stdin file descriptor on the event loop with a callback that forwards input typed on GDB's terminal to the inferior's tty. - Similarly, when GDB receives a SIGWINCH signal, meaning GDB's terminal was resized, GDB resizes the inferior's terminal too. - GDB puts the inferior in its own session, and there's a "session leader" process between GDB and the inferior. The latter is because session leaders have special properties, one of which is, if they exit, all progresses in the foreground process group in the session get a SIGHUP. If the spawned inferior was the session leader itself, if you were debugging an inferior that forks and follow to the child, if the parent (the session leader) exits, then the child would get a SIGHUP. Forking twice when launching an inferior, and making the first child be the session leader, and the second child the inferior avoids that problem. - When the inferior exits or is killed, GDB sends a SIGHUP to the session leader, waits for the leader to exit and then destroys the terminal. The session leader's SIGHUP handler makes the session leader pgrp be the foreground process group and then exits. This sequence is important comparing to just closing the terminal and letting the session leader terminate due to the SIGHUP the kernel sends, because when the session leader exits, all processes in the foreground process group get a SIGHUP, meaning that if the detached process was still in the foreground, it would get a SIGHUP, and likely die. - The gdb.multi/multi-term-settings.exp was adjusted to test for shared and not-shared terminal/session. Without the change, we get failures: FAIL: gdb.multi/multi-term-settings.exp: inf1_how=run: inf2_how=run: continue (expected SIGTTOU) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=run: inf2_how=run: stop with control-c (Quit) Tested on GNU/Linux native, gdbserver and gdbserver + "maint target set-non-stop on". Also build-tested tested on mingw32-w64, Solaris 11, and OpenBSD. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * fork-child.c (child_has_managed_tty_hook): New. * inf-ptrace.c (inf_ptrace_me): If we created a managed tty, raise SIGSTOP. (inf_ptrace_handle_session_leader_fork): New. (inf_ptrace_target::create_inferior): Pass it down as handle_session_leader_fork callback. * inf-ptrace.h (inf_ptrace_target) <handle_session_leader_fork>: New virtual method. * inferior.h (child_terminal_on_sigwinch): Declare. * inflow.c: Include "gdbsupport/event-loop.h", "gdbsupport/refcounted-object.h", "gdbsupport/gdb_wait.h", "gdbsupport/managed-tty.h". (USES_FORK_CHILD): Define, and wrap fork-child.c-related code with it. (struct run_terminal_info): New. (struct terminal_info) <run_terminal>: Now a run_terminal_info. <process_group>: Default to -1. <save_from_tty>: New method. (sigint_ours): Update comments. (inferior_thisrun_terminal_pty_fd): New. (input_fd_redirected): New. (sharing_input_terminal): Adjust. (gdb_tcgetattr, gdb_tcsetattr, make_raw, class scoped_raw_termios) (child_terminal_flush_from_to, child_terminal_flush_stdout) (inferior_stdout_event_handler, inferior_stdin_event_handler): New. (child_terminal_inferior): Handle inferiors with gdb-managed ttys. (child_terminal_save_inferior): Handle inferiors with gdb-managed ttys. Use save_from_tty. (child_terminal_ours_1): Handle inferiors with gdb-managed ttys. (terminal_info::~terminal_info): Use delete instead of xfree. (child_terminal_on_sigwinc): New. (inflow_inferior_exit): Release terminal created by GDB. (copy_terminal_info): Assert there's no run_terminal yet in TO yet. Incref run_terminal after copying. (child_terminal_info): Handle inferiors with gdb-managed ttys. (new_tty_prefork): Allocate pseudo-terminal. (created_managed_tty): New. (new_tty): Remove __GO32__ and _WIN32 #ifdefs, not needed given USES_FORK_CHILD. (new_tty_postfork): Handle inferiors with gdb-managed ttys. (show_debug_managed_tty): New. (_initialize_inflow): Register "set/show debug managed-tty". * linux-nat.c (waitpid_sigstop, waitpid_fork) (linux_nat_target::handle_session_leader_fork): New. * linux-nat.h (linux_nat_target) <handle_session_leader_fork>: Declare override. * nat/fork-inferior.c: Include "gdbsupport/scoped_ignore_sigttou.h", "gdbsupport/managed-tty.h", <sys/types.h> and <sys/wait.h>. (session_leader_hup): New. (fork_inferior): Add handle_session_leader_fork parameter. If the inferior has a gdb-managed tty, don't use vfork, and fork twice, with the first fork becoming the session leader. Call handle_session_leader_fork. * nat/fork-inferior.h (fork_inferior): Add handle_session_leader_fork parameter and update comment. (child_has_managed_tty_hook): Declare. * terminal.h (created_managed_tty, child_gdb_owns_session): Declare. * tui/tui-win.c: Include "inferior.h". (tui_async_resize_screen): Call child_terminal_on_sigwinch. gdbsupport/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * Makefile.am (libgdbsupport_a_SOURCES): Add managed-tty.cc. * Makefile.in: Regenerate. * managed-tty.cc: New. * managed-tty.h: New. gdbserver/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * fork-child.cc (child_has_managed_tty_hook): New. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * gdb.multi/multi-term-settings.exp (create_inferior): Document "run-session", "run-share" and "run-tty" instead of "run" and "tty". Adjust to handle "run-session" vs "run-share". (coretest): Adjust to handle "run-session" vs "run-share". (how_modes): Use "run-session", "run-share" and "run-tty" instead of "run" and "tty". Change-Id: I2569e189294044891e68a66401b381e4b999b19c
2021-06-14Move scoped_ignore_sigttou to gdbsupport/Pedro Alves6-9/+6
A following patch will want to use scoped_ignore_sigttou in code shared between GDB and GDBserver. Move it under gdbsupport/. Note that despite what inflow.h/inflow.c's first line says, inflow.c is no longer about ptrace, it is about terminal management. Some other files were unnecessarily including inflow.h, I guess a leftover from the days when inflow.c really was about ptrace. Those inclusions are simply dropped. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * Makefile.in (HFILES_NO_SRCDIR): Remove inflow.h. * inf-ptrace.c, inflow.c, procfs.c: Don't include "inflow.h". * inflow.h: Delete, moved to gdbsupport/ under a different name. * ser-unix.c: Don't include "inflow.h". Include "gdbsupport/scoped_ignore_sigttou.h". gdbsupport/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * scoped_ignore_sigttou.h: New file, moved from gdb/ and renamed. Change-Id: Ie390abf42c3a78bec6d282ad2a63edd3e623559a
2021-06-14target_terminal::ours_for_output before printing signal receivedPedro Alves1-1/+4
A following patch will make GDB put spawned inferiors in their own terminal/session (on GNU/Linux). In that case, GDB is in control of when is the inferior's output flushed to the screen. A sync point is when target_terminal state goes from inferior -> ours/ours_for_output. The gdb.multi/multi-term-settings.exp testcase exposed a bug where an inferior output flush is missing, resulting in this regression: Good: (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: info inferiors continue Continuing. pid=1275538, count=0 pid=1276069, count=0 Thread 1.1 "multi-term-sett" received signal SIGTTOU, Stopped (tty output). [Switching to process 1275538] 0x00007ffff7ecda14 in __tcsetattr (fd=0, optional_actions=0, termios_p=0x7fffffffd450) at ../sysdeps/unix/sysv/linux/tcsetattr.c:83 83 ../sysdeps/unix/sysv/linux/tcsetattr.c: No such file or directory. (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: continue (expected SIGTTOU) Quit (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: stop with control-c (Quit) Bad: (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: info inferiors continue Continuing. pid=1287638, count=0 Thread 1.1 "multi-term-sett" received signal SIGTTOU, Stopped (tty output). pid=1287663, count=0 <<<<<< HERE [Switching to process 1287638] 0x00007ffff7ecda14 in __tcsetattr (fd=0, optional_actions=0, termios_p=0x7fffffffd450) at ../sysdeps/unix/sysv/linux/tcsetattr.c:83 83 ../sysdeps/unix/sysv/linux/tcsetattr.c: No such file or directory. (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: continue Quit (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=run-share: inf2_how=run-session: stop with control-c (Quit) Notice the "<<<<<< HERE" line in the "Bad" output above -- that is inferior output being printed on the screen _after_ GDB says the thread stopped... That's obviously bogus, the output was printed by the inferior before it was stopped. The fix is to claim back the terminal for output before printing the "signal received SIGTTOU" message. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * infrun.c (normal_stop): Call target_terminal::ours_for_output before calling signal_received observers. Change-Id: Iea106c33b4c585562fc3579ca85d43481fa214f0
2021-06-14gdb.mi/mi-logging.exp, don't send input to GDB while the inferior is runningPedro Alves1-17/+77
The gdb.mi/mi-logging.exp testcase sends a sequence of execution commands to the GDB terminal while the inferior is running, like this: send_gdb "1002-exec-step\n" send_gdb "1003-exec-next\n" expecting that GDB will consume the "1003-exec-next" intput after the inferior stops for the 1002-exec-step. That's a flawed assumption in general, because the inferior itself could consume the "1003-exec-next" input while it is stepping. When GDB puts the inferior in its own terminal, while the inferior is running, GDB marshals input from its terminal to the inferior's terminal. The result is that input typed while the inferior is running never goes to GDB, and so the test fails. The previous patch addressed issues like this by making the inferior and GDB share the same terminal for tests that really wanted to test some aspect of a shared terminal. For gdb.mi/mi-logging.exp though, there's really no reason to send input while the program is running, so the fix here is to stop it from doing so. While debugging the testcase, I ran into the fact that it reuses the same log file for more than one [open] sequence, overwriting previous runs. The testcase also deletes the log files at the very end, which makes it impossible to inspect the logs after a failure run. The patch addresses those issues as well. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.mi/mi-logging.exp: Do not reuse log files for different runs. Delete logs at the start of the testcase, not at the end. (wait_open, gdb_test_file): New procedures. Use them. Change-Id: Ife215a82391a020041fd05478bd8dbee6e04d607
2021-06-14Make inferior/GDB share terminal in tests that exercise GDB/inferior reading ↵Pedro Alves3-1/+18
same input Some testcases exercise some aspect that only makes sense when GDB and the inferior are sharing the same terminal, meaning GDB and the inferior are reading from the same input file. This commit makes sure that continues to be tested even after GDB changed to put inferiors in their own session/terminal by default, by issuing "tty /dev/tty". The tests would fail otherwise. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.base/annota-input-while-running.exp: Issue "tty /dev/tty" before starting program. * gdb.base/continue-all-already-running.exp: Likewise. * gdb.base/infcall-input.exp: Likewise. Change-Id: Ia5f9061bf28a5e780194aa75b37b6058de0614ee
2021-06-14Make inferior/GDB share terminal in tests expecting output after detachPedro Alves1-0/+3
A following patch will make GDB put spawned inferiors in their own terminal/session. A consequence of that is that if you do "run", and then "detach", GDB closes the terminal, so expecting inferior output after detach no longer works, the inferior is alive, but its output goes nowhere. There's only one testcase that expects output out of an inferior after detach. Tweak it to output to GDB's terminal instead. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.threads/process-dies-while-detaching.exp: Issue "tty /dev/tty" before starting program. Change-Id: Ic62bca178295763fb9c47657ee459fe715f7865e
2021-06-14Special-case "set inferior-tty /dev/tty"Pedro Alves1-9/+17
The following patches will make GDB spawn inferiors in their own session and tty by default. Meaning, GDB will create and manage a pty for the inferior instead of the inferior and GDB sharing the same terminal and GDB having to juggle terminal settings depending on whether the inferior running or gdb showing the prompt. For some use cases however, it will still be useful to be able to tell GDB to spawn the inferior in the same terminal & session as GDB, like today. Setting the inferior tty to "/dev/tty" seems like an obvious way to get that, as /dev/tty is a special file that represents the terminal for the current process. This leaves "tty" with no arguments free for a different behavior. This patch hardcodes "/dev/tty" in is_gdb_terminal for that reason. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * inflow.c (is_gdb_terminal): Hardcode "/dev/tty". (new_tty): Don't create a tty if is_gdb_terminal is true. (new_tty_postfork): Always allocate a run_terminal. (create_tty_session): Don't create a session if sharing the terminal with GDB. Change-Id: I4dc7958f823fa4e30c21a2c3fe4d8434a5d5ed40
2021-06-14Don't check parent pid in ↵Pedro Alves3-15/+0
gdb.threads/{ia64-sigill,siginfo-threads,watchthreads-reorder}.c A following patch will make GDB always put spawned inferiors in their own terminal session. To do that, GDB forks twice, creating an extra "session leader" process between gdb and the inferior process. gdb.threads/{ia64-sigill,siginfo-threads,watchthreads-reorder}.c all check whether the parent process is GDB. If it isn't, they just bail, and the testcase fails. After the changes mentioned above, this parent check will fail if GDB is putting inferiors in their own terminal session, because in that case, the test's parent is the extra "session leader" process between gdb and the test process. The tracer will be the test process's grandparent, not the direct parent. Since the test programs already check whether there's a ptracer attached, there's no real need for this parent pid check. Just remove it. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.threads/ia64-sigill.c (main): Don't check whether the parent pid is the tracer. * gdb.threads/siginfo-threads.c (main): Don't check whether the parent pid is the tracer. * gdb.threads/watchthreads-reorder.c (main): Don't check whether the parent pid is the tracer. Change-Id: Iea0b06fb93c31bde1a0993c52b3fe8a5f408aec7
2021-06-14Fix gdb.multi/multi-term-settings.exp racePedro Alves1-6/+34
The gdb.multi/multi-term-settings.exp testcase sometimes fails like so: Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ... FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) It's easier to reproduce if you stress the machine at the same time, like e.g.: $ stress -c 24 Looking at gdb.log, we see: (gdb) attach 60422 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422 [New Thread 60422.60422] Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so... Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe23126940, rem=rem@entry=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory. (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach set schedule-multiple on (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on info inferiors Num Description Connection Executable 1 process 60404 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings * 2 process 60422 1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors pid=60422, count=46 pid=60422, count=47 pid=60422, count=48 pid=60422, count=49 pid=60422, count=50 pid=60422, count=51 pid=60422, count=52 pid=60422, count=53 pid=60422, count=54 pid=60422, count=55 pid=60422, count=56 pid=60422, count=57 pid=60422, count=58 pid=60422, count=59 pid=60422, count=60 pid=60422, count=61 pid=60422, count=62 pid=60422, count=63 pid=60422, count=64 pid=60422, count=65 pid=60422, count=66 pid=60422, count=67 pid=60422, count=68 pid=60422, count=69 pid=60404, count=54 pid=60404, count=55 pid=60404, count=56 pid=60404, count=57 pid=60404, count=58 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue Quit (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT) If you look at the testcase's sources, you'll see that the intention is to resumes the program with "continue", wait to see a few of those "pid=..., count=..." lines, and then interrupt the program with Ctrl-C. But somehow, that resulted in GDB printing "Quit", instead of the Ctrl-C stopping the program with SIGINT. Here's what is happening: #1 - those "pid=..., count=..." lines we see above weren't actually output by the inferior after it has been continued (see #1). Note that "inf1_how" and "inf2_how" are "attach". What happened is that those "pid=..., count=..." lines were output by the inferiors _before_ they were attached to. We see them at that point instead of earlier, because that's where the testcase reads from the inferiors' spawn_ids. #2 - The testcase mistakenly thinks those "pid=..., count=..." lines happened after the continue was processed by GDB, meaning it has waited enough, and so sends the Ctrl-C. GDB hasn't yet passed the terminal to the inferior, so the Ctrl-C results in that Quit. The fix here is twofold: #1 - flush inferior output right after attaching #2 - consume the "Continuing" printed by "continue", indicating the inferior has the terminal. This is the same as done throughout the testsuite to handle this exact problem of sending Ctrl-C too soon. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.multi/multi-term-settings.exp (create_inferior): Flush inferior output. (coretest): Use $gdb_test_name. After issuing "continue", wait for "Continuing". Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9
2021-06-14Make gdb.base/long-inferior-output.exp fail fastPedro Alves1-3/+28
A local change I was working on had a bug that made GDB lose inferior output, which was caught by the gdb.base/long-inferior-output.exp testcase. While debugging the problem, I found it useful to have the testcase fail quickly when it noticed output was missing. Also, tighten the regexes to make sure that we don't get spurious/repeated/bogus output between each "this is line number ..." line. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.base/long-inferior-output.exp: Don't set "more" when we see an unexpected "this is line number" number. Change-Id: I53e8499bd8fdbf961431a7f2a94d263da6a9f573
2021-06-14prefork_hook: Remove 'args' parameterPedro Alves4-12/+6
prefork_hook's 'args' parameter is only used in debug output in gdbserver. Remove it. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * fork-child.c (prefork_hook): Remove 'args' parameter. All callers adjusted. * nat/fork-inferior.h (prefork_hook): Remove 'args' parameter. All callers adjusted. * nat/fork-inferior.c (fork_inferior): Adjust. gdbserver/fork-child.cc yyyy-mm-dd Pedro Alves <pedro@palves.net> * fork-child.cc (prefork_hook): Remove 'args' parameter, and references. Change-Id: Iaf8977af7dd6915c123b0d50ded93395bdafd920
2021-06-14Test interrupting programs that block SIGINT [gdb/9425, gdb/14559]Pedro Alves4-0/+329
This adds a couple testcases that exercise interrupting programs that block SIGINT. One tests a program that uses sigprocmask to mask out SIGINT, and the other tests a program that waits for SIGINT with sigwait. On GNU/Linux, it is currently impossible to interrupt such a program with Ctrl-C, and you can't interrupt it with the "interrupt" command in all-stop mode either. These currently fail, and are suitably kfailed. The rest of the series will fix the fails. Tested on GNU/Linux native, gdbserver, and gdbserver + "maint set target-non-stop on". gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> PR gdb/9425 PR gdb/14559 * gdb.base/sigint-masked-out.c: New file. * gdb.base/sigint-masked-out.exp: New file. * gdb.base/sigint-sigwait.c: New file. * gdb.base/sigint-sigwait.exp: New file. Change-Id: Iddb70c0a2c92550027fccb6f51ecba1292d233c8
2021-06-14Fix silent gdb.base/annota1.exp test coverage regressionPedro Alves2-3/+12
This commit fixes a test coverage regression caused by: commit b001de2320446ec803b4ee5e0b9710b025b84469 Author: Andrew Burgess <andrew.burgess@embecosm.com> AuthorDate: Mon Nov 26 17:56:39 2018 +0000 Commit: Andrew Burgess <andrew.burgess@embecosm.com> CommitDate: Wed Dec 12 17:33:52 2018 +0000 gdb: Update test pattern to deal with native-extended-gdbserver While looking at a regression caused by a local patch I was working on, I noticed this: pre-prompt (gdb) prompt PASS: gdb.base/annota1.exp: breakpoint info PASS: gdb.base/annota1.exp: run until main breakpoint run post-prompt Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.base/annota1/annota1 next Note how above, we get the "run until main breakpoint" pass even before "run" shows up in the log! The issue is that the test isn't really testing anything, it always passes regardless of the gdb output. There are a few problems here, fixed by this commit: - using {} to build the list for [join], when the strings we're joining include variable names that must be expanded. Such list need to be built with [list] instead. - [join] joins strings with a space character by default. We need to pass the empty string as second parameter so that it just concats the strings. - doing too much in a "-re" (calling procedures), which doesn't work correctly. I've seen this before and never digged deeper into why. Probably something to do with how gdb_test_multiple is implemented. Regardless, easy and clear enough to build the pattern first into a variable. gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.base/annota1.exp: Build list using [list] instead of {}. Tell [join] to join with no character. Build expected pattern in separate variable instead of in the -re expression directly. Change-Id: Ib3c89290f0e9ae4a0a43422853fcd4a7a7e12b18
2021-06-14Include missing header signal.hBernd Edlinger2-0/+5
2021-06-14 Bernd Edlinger <bernd.edlinger@hotmail.de> * compile/compile.c: Include missing header signal.h.
2021-06-14Use consistent type in binutils/dwarf.cEric Botcazou2-10/+17
If you look at the type used for implicit_const objects in binutils/dwarf.c, you'll get sometimes bfd_signed_vma and sometimes dwarf_signed_vma. They are the same on 64-bit hosts, but not on 32-bit hosts, and the latter discrepancy, in particular in process_abbrev_set, is responsible for the following error issued by objdump on some object files containing DWARF 5: binutils/dwarf.c:1108: read LEB value is too large to store in destination variable binutis/ * dwarf.c (struct abbrev_attr): Change type of implicit_const. (add_abbrev_attr): Likewise. (process_abbrev_set): Likewise. (display_debug_abbrev): Adjust to above change.
2021-06-14GNU gettext introduced this change[0] in version 0.19.8 to fix gettext ↵Michael Forney4-20/+67
detection with musl libc, since it does not define these internal symbols. This allows binutils to build with musl gettext rather than falling back to the bundled version. [0] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=b67399b4 2021-06-13 Michael Forney <mforney@mforney.org> config/ChangeLog: * gettext.m4 (AM_GNU_GETTEXT): Skip checks for the internal symbols _nl_msg_cat_cntr, _nl_domain_bindings, and _nl_expand_alias, if __GNU_GETTEXT_SUPPORTED_REVISION is defined. Backport of gettext serial 68 patch. intl/ChangeLog: * configure: Regenerate. --- Thi
2021-06-14gas: fold three as_warn() in emit_expr_with_reloc()Jan Beulich2-12/+6
Simply use the available abstraction instead of, effectively, trying to open-code it.
2021-06-14gas: drop TC_ADDRESS_BYTES conditionalsJan Beulich3-5/+8
I've been repeatedly confused by, in particular, the .dc.a potable[] entry being conditional. Grepping in gas/config/ reveals only very few targets actually #define-ing it. But as of 7be1c4891a20 the symbol is always defined, so #ifdef-s are pointless (and, as said, potentially confusing). Also adjust documentation to reflect this.
2021-06-13sim: ppc: use common version.o tooMike Frysinger2-7/+10
The common version.o we're building can be used for the ppc subdir, so switch it over too.
2021-06-13sim: rx: move cycle-accurate settings to CPPFLAGSMike Frysinger5-10/+15
This is the last unique setting that rx has in its config.h, so by moving this to CPPFLAGS, we can drop its config.h entirely.
2021-06-14Automatic date update in version.inGDB Administrator1-1/+1
2021-06-12sim: start unifying portability shimsMike Frysinger12-19/+157
There are some functions that gnulib does not yet provide fallbacks for, so start a common file of our own for holding existing stubs.
2021-06-12sim: unify sim-load.o buildingMike Frysinger6-5/+74
Since this file does not rely on any port-specific settings, move it up to building as part of the common step so we only do it once in a multibuild.
2021-06-12sim: rx: replace cycle-stats with common profile settingsMike Frysinger7-63/+29
The common sim-profile option controls whether to keep track of runtime execution (like cycle count), so switch the rx-specific cycle-stats option over to that.
2021-06-12sim: assume sys/select.h always existsMike Frysinger13-15/+25
Now that gnulib provides this, assume it exists.
2021-06-12sim: erc32: replace caddr_t with void*Mike Frysinger2-10/+18
This BSDism was never accepted into standards, so replace it with the portable void* type instead.
2021-06-12sim: erc32/ppc: fix handling of $EXEEXTMike Frysinger4-6/+14
2021-06-12sim: overhaul alignment settings managementMike Frysinger136-1616/+334
Currently, the sim-config module will abort if alignment settings haven't been specified by the port's configure.ac. This is a bit weird when we've allowed SIM_AC_OPTION_ALIGNMENT to seem like it's optional to use. Thus everyone invokes it. There are 4 alignment settings, but really only 2 matters: strict and nonstrict. The "mixed" setting is just the default ("unset"), and "forced" isn't used directly by anyone (it's available as a runtime option for some ports). The m4 macro has 2 args: the "wire" settings (which represents the hardwired port behavior), and the default settings (which are used if nothing else is specified). If none are specified, then the build won't work (see above as if SIM_AC_OPTION_ALIGNMENT wasn't called). If default settings are provided, then that is used, but we allow the user to override at runtime. Otherwise, the "wire" settings are used and user runtime options to change are ignored. Most ports specify a default, or set the "wire" to nonstrict. A few set "wire" to strict, but it's not clear that's necessary as it doesn't make the code behavior, by default, any different. It might make things a little faster, but we should provide the user the choice of the compromises to make: force a specific mode at compile time for faster runtime, or allow the choice at runtime. More likely it seems like an oversight when these ports were initially created, and/or copied & pasted from existing ports. With all that backstory, let's get to what this commit does. First kill off the idea of a compile-time default alignment and set it to nonstrict in the common code. For any ports that want strict alignment by default, that code is moved to sim_open while initializing the sim. That means WITH_DEFAULT_ALIGNMENT can be completely removed. Moving the default alignment to the runtime also allows removal of setting the "wire" settings at configure time. Which allows removing of all arguments to SIM_AC_OPTION_ALIGNMENT and moving that call to common code. The macro logic can be reworked to not pass WITH_ALIGNMENT as -D CPPFLAG and instead move it to config.h. All of these taken together mean we can hoist the macro up to the top level and share it among all sims so behavior is consistent among all the ports.
2021-06-12sim: unify bug & package settingsMike Frysinger105-2785/+165
Move these options up to the common dir so we only test & export them once across all ports. The AC_INIT macro does a lot of the heavy lifting already which allows further simplification.
2021-06-12sim: unify debug/stdio/trace/profile build settingsMike Frysinger73-4742/+244
Move these options up to the common dir so we only test & export them once across all ports. The ppc code needs a little extra care with its trace settings as it's not exactly the same API as the common code. The other knobs are the same though.
2021-06-12sim: split debug/stdio/trace/profile options into dedicated m4 filesMike Frysinger6-95/+178
This follows existing organizational structure with one configure option per m4 file, and will make it easier to move to the common configure dir.
2021-06-13Automatic date update in version.inGDB Administrator1-1/+1
2021-06-12sim: ppc: unify header & function & type tests tooMike Frysinger8-1081/+902
Since ppc now shares a config.h with the top-level, move all of its relevant settings up a level. The ppc port tests a lot more funcs, but that's because its syscall emulation is a lot more complete. We'll probably utilize some of these in the common code too.
2021-06-12remote: Fix indentation in remote_new_objfile.John Baldwin2-2/+6
gdb/remote.c:14541:5: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (current_inferior ()->in_initial_library_scan) ^ gdb/remote.c:14527:3: note: previous statement is here if (remote == nullptr) ^ gdb/ChangeLog: * remote.c (remote_new_objfile): Fix indentation.
2021-06-12sim: ppc: unify env settings tooMike Frysinger6-45/+23
The ppc port doesn't share a lot of the common logic, but there are a few bits that bleed across. Have it use the common configure for environment settings too to avoid duplicate define errors after the recent unification with the other ports.
2021-06-12sim: unify environment build settingsMike Frysinger100-993/+100
Move the --sim-enable-environment option up to the common dir so we only test & export it once across all ports.
2021-06-12sim: unify assert build settingsMike Frysinger131-869/+222
Move the --sim-enable-assert option up to the common dir so we only test & export it once across all ports.
2021-06-12sim: unify platform function & header testsMike Frysinger109-17440/+1478
Move the various platform tests up a level to avoid duplication across the ports. When building multiple versions, this speeds things up a bit. For now we move the obvious stuff up a level, but we don't turn own the config.h entirely just yet -- we still have some tests related to libraries that need consideration.
2021-06-12readelf: don't clear section_headers in process_file_headerAlan Modra2-2/+4
* readelf.c (process_file_header): Don't clear section_headers.
2021-06-12Re: readelf section readingAlan Modra2-3/+12
Fix commit 4de91c10cdd9, which cached the single section header read to pick up file header extension fields. Also, testing e_shoff in get_section_headers opened a hole for fuzzers where we'd end up with segfaults due to non-zero e_shnum but NULL section_headers. * readelf.c (get_section_headers): Don't test e_shoff here, leave that to get_32bit_section_headers or get_64bit_section_headers. (process_object): Throw away section header read to print file header extension.
2021-06-12Automatic date update in version.inGDB Administrator1-1/+1
2021-06-11Fix ChangeLog entry locationSimon Marchi2-14/+14
This ChangeLog entry is in the wrong file, fix that. Change-Id: I43464e1bdb94d2f40d4c7dfaf425fc498851964c
2021-06-11mi-sym-info.exp: Increase timeout for 114-symbol-info-functionsKevin Buettner2-27/+34
Loading libc.so's symbols increased the amount of time needed for 114-symbol-info-function to fetch symbols, causing a timeout during my testing. I enclosed the entire block with a "with_timeout_factor 4", which fixes the problem for me. (Using 2 also fixed it for me, but it might not be enough when running this test on slower machines.) gdb/testsuite/ChangeLog: * gdb.mi/mi-sym-info.exp (114-symbol-info-function test): Increase timeout.
2021-06-11print-symbol-loading.exp: Allow libc symbols to be already loadedKevin Buettner2-3/+17
One consequence of changing libpthread_name_p() in solib.c to (also) match libc is that the symbols for libc will now be loaded by solib_add() in solib.c. I think this is mostly harmless because we'll likely want these symbols to be loaded anyway, but it did cause two failures in gdb.base/print-symbol-loading.exp. Specifically... 1) sharedlibrary .* (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib now looks like this: sharedlibrary .* Symbols already loaded for /lib64/libc.so.6 (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib 2) sharedlibrary .* Loading symbols for shared libraries: .* (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib brief: load shared-lib now looks like this: sharedlibrary .* Loading symbols for shared libraries: .* Symbols already loaded for /lib64/libc.so.6 (gdb) PASS: gdb.base/print-symbol-loading.exp: shlib brief: load shared-lib Fixing case #2 ended up being easier than #1. #1 had been using gdb_test_no_output to correctly match this no-output case. I ended up replacing it with gdb_test_multiple, matching the exact expected output for each of the two now acceptable cases. For case #2, I simply added an optional non-capturing group for the potential new output. gdb/testsuite/ChangeLog: * gdb.base/print-symbol-loading.exp (proc test_load_shlib): Allow "Symbols already loaded for..." messages.
2021-06-11testsuite/glib-2.34: Match/consume optional libthread_db related outputKevin Buettner3-1/+10
When using glibc-2.34, we now see messages related to the loading of the thread library for non-thread programs. E.g. for the test case, gdb.base/execl-update-breakpoints.exp, we will see the following when starting the program: (gdb) break -qualified main Breakpoint 1 at 0x100118c: file /ironwood1/sourceware-git/f34-2-glibc244_fix/bld/../../worktree-glibc244_fix/gdb/testsuite/gdb.base/execl-update-breakpoints.c, line 34. (gdb) run Starting program: [...]/execl-update-breakpoints1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". The two lines of output related to libthread_db are new; we didn't see these in the past. This is a side effect of libc now containing the pthread API - we can no longer tell whether the program is multi-threaded by simply looking for libpthread.so. That said, I think that we now want to load libthread_db anyway since it's used to resolve TLS variables; i.e. we need it for correctly determining the value of errno. This commit adds the necessary regular expressions to match this (optional) additional output in the two tests which were failing without it. gdb/testsuite/ChangeLog: * gdb.base/execl-update-breakpoints.exp: Add regular expression for optionally matching output related to libthread_db. * gdb.base/fork-print-inferior-events.exp: Likewise.
2021-06-11libthread_db initialization changes related to upcoming glibc-2.34Kevin Buettner3-5/+36
This commit makes some adjustments to accomodate the upcoming glibc-2.34 release. Beginning with glibc-2.34, functionality formerly contained in libpthread has been moved to libc. For the time being, libpthread.so still exists in the file system, but it won't show up in ldd output and therefore won't be able to trigger initialization of libthread_db related code. E.g... Fedora 34 / glibc-2.33.9000: [kev@f34-2 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls linux-vdso.so.1 (0x00007ffcf94fa000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff0ba9af000) libm.so.6 => /lib64/libm.so.6 (0x00007ff0ba8d4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff0ba8b9000) libc.so.6 => /lib64/libc.so.6 (0x00007ff0ba6c6000) /lib64/ld-linux-x86-64.so.2 (0x00007ff0babf0000) Fedora 34 / glibc-2.33: [kev@f34-1 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls linux-vdso.so.1 (0x00007fff32dc0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f815f6de000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f815f4bf000) libm.so.6 => /lib64/libm.so.6 (0x00007f815f37b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f815f360000) libc.so.6 => /lib64/libc.so.6 (0x00007f815f191000) /lib64/ld-linux-x86-64.so.2 (0x00007f815f721000) Note that libpthread is missing from the ldd output for the glibc-2.33.9000 machine. This means that (unless we happen to think of some entirely different mechanism), we'll now need to potentially match "libc" in addition to "libpthread" as libraries which might be thread libraries. This accounts for the change made in solib.c. Note that the new code attempts to match "/libc." via strstr(). That trailing dot (".") avoids inadvertently matching libraries such as libcrypt (and all the other many libraries which begin with "libc"). To avoid attempts to load libthread_db when encountering older versions of libc, we now attempt to find "pthread_create" (which is a symbol that we'd expect to be in any pthread library) in the associated objfile. This accounts for the changes in linux-thread-db.c. I think that other small adjustments will need to be made elsewhere too. I've been working through regressions on my glibc-2.33.9000 machine; I've fixed some fairly "obvious" changes in the testsuite (which are in other commits). For the rest, it's not yet clear to me whether the handful of remaining failures represent a problem in glibc or gdb. I'm still investigating, however, I'll note that these are problems that I only see on my glibc-2.33.9000 machine. gdb/ChangeLog: * solib.c (libpthread_name_p): Match "libc" in addition to "libpthread". * linux-thread-db.c (libpthread_objfile_p): New function. (libpthread_name_p): Adjust preexisting callers to use libpthread_objfile_p().
generated by cgit v1.1 at 2025-09-18 13:06:07 +0000