How to fix an ancient GDB problem

Posted Sep 30, 2022 7:53 UTC (Fri) by rwmj (subscriber, #5474)
Parent article: How to fix an ancient GDB problem

Perhaps I misunderstand how this works, but if GDB connects to or disconnects from an existing process is it able to change the process's terminal to the new pty and then reset it back to the regular terminal later?

How to fix an ancient GDB problem

Posted Sep 30, 2022 13:19 UTC (Fri) by gray_-_wolf (subscriber, #131074) [Link]

I would assume this will work only when starting new process and not when attaching to existing one?

How to fix an ancient GDB problem

Posted Sep 30, 2022 13:51 UTC (Fri) by fw (subscriber, #26023) [Link] (1 responses)

When attaching to a running process, you just have to hit Ctrl+C in the terminal running GDB, as before. This mode of operation hasn't really suffered from these problems, as far as I understand it.

How to fix an ancient GDB problem

Posted Oct 4, 2022 11:52 UTC (Tue) by palves (guest, #91099) [Link]

> When attaching to a running process, you just have to hit Ctrl+C in the terminal running GDB, as before. This mode of
> operation hasn't really suffered from these problems, as far as I understand it.

When you attach to process running in another terminal, and hit Ctrl-C in the terminal running GDB, that Ctrl-C is turned into a SIGINT sent to GDB. So that half of the problem does not exist in that scenario, GDB sees the SIGINT first, not the inferior. However, currently, in "I am attached" scenario, GDB forwards that SIGINT to the target process, using plain "kill(pid, SIGINT)", and then relies on ptrace intercepting that SIGINT. If the target process blocks SIGINT, then you're back to square 1. To get that scenario working properly, we stil need part of the proposal in place, specifically the part about pausing the target process in a different way, with SIGSTOP.