On Saturday 11 October 2008 00:27:06, Thomas Schwinge wrote:
> On HEAD, when undoing this change (and additionally commenting out the
> two ``stop_soon = X'' lines in that file), things are fine again.
>
> As most of GDB's internals are a big black box to me, I need help here.
> :-)
>
Eh, I did point out at the time of that change that gnu-nat.c does
things a bit different. :-)
Off-hand advice:
One thing that the hurd has a bit different, is that we have
multi-threading when going through the shell.
Could it be that target_wait is returning a specific ptid here:
fork_child.c:startup_inferior:
while (1)
{
int resume_signal = TARGET_SIGNAL_0;
ptid_t resume_ptid;
struct target_waitstatus ws;
memset (&ws, 0, sizeof (ws));
resume_ptid = target_wait (pid_to_ptid (-1), &ws);
^^^^^^^^^^^
Hence this a bit below:
if (--pending_execs == 0)
break;
/* Just make it go on. */
target_resume (resume_ptid, 0, TARGET_SIGNAL_0);
^^^^^^^^^^^
}
}
Doesn't resume the whole shell?
If you make this change:
- target_resume (resume_ptid, 0, TARGET_SIGNAL_0);
+ target_resume (minus_one_ptid, 0, TARGET_SIGNAL_0);
The other thing I suggest to look at, is to make sure the
local `pending_execs' and the `gnu-nat.c:struct inf'::pending_execs
aren't in conflict, but it doesn't look like it.
Hope this helps.
--
Pedro Alves
