Hmm. I am not in a position to actually debug this, but I am reading the gdb sources and I think I understand what is happening. In gdb/inflow.c is the following comment and code, which gets run when you do an "attach" (among other times).
/* If attach_flag is set, we don't know whether we are sharing a terminal with the inferior or not. (attaching a process without a terminal is one case where we do not; attaching a process which we ran from the same shell as GDB via `&' is one case where we do, I think (but perhaps this is not `sharing' in the sense that we need to save and restore tty state)). I don't know if there is any way to tell whether we are sharing a terminal. So what we do is to go through all the saving and restoring of the tty state, but ignore errors setting the process group, which will happen if we are not sharing a terminal). */ result = tcsetpgrp (0, inferior_process_group); As the comment says, this might not be something that should be done. In your case of attaching to a process that's on another terminal, changing the pgrp should not be done. This code relies on tcsetpgrp to refuse to change the pgrp (and return EPERM instead) when the inferior process is not in the same session as gdb. POSIX.1 requires this error be reported in that case, but the Hurd doesn't do it. You've actually stumbled onto a pretty subtle oversight that only came to light because of this odd usage. But gdb's usage is perfectly correct and reasonable according to the standard. The code in term that implements tcsetpgrp (which is just the TIOCSPGRP ioctl, aka the tioctl_tiocspgrp RPC) doesn't check the pgrp value at all. So what happens is this tcsetpgrp call succeeds in changing the pgrp of the terminal, so C-c et al send signals to the wrong process (which won't accept them, because they don't use its proper ctty port). I'm not sure what the best way to fix this is; it might not be pretty. The required check is that the calling process be in the same session as the pgrp it specifies. One way to establish this is something like requiring that the caller present the session ID port, but that leaks a capability that term doesn't ordinarily have. term can also just do getsid on the pid given in term_ctty_open for that protid, but there is no kind of constraint on what pid the client passes there, so it is not a secure check. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd