Re: behaviour when only running thread exits (non-stop mode)

[Doug Evans <dje at google dot com>]

On Tue, Mar 24, 2009 at 12:16 PM, Doug Evans <dje@google.com> wrote:
> On Tue, Mar 24, 2009 at 11:33 AM, Doug Evans <dje@google.com> wrote:
>> What's the intended behaviour, as far as what the user sees, when the
>> only running thread exits in non-stop mode?
>> [where this thread is not the main thread, and there can be any number
>> of other threads, they're just not running - e.g. the user is
>> singlestepping one thread in non-stop mode]
>>
>> Currently gdb is hanging because thread exits are ignored (in the
>> TARGET_WAITKIND_IGNORE sense), and with no thread running even ^c's
>> passed to the target (via pass_signal) won't get the command prompt
>> back.
>>
>> Non-stop mode is not supposed to automagically switch threads on the
>> user, so it seems like gdb shouldn't randomly switch to another
>> thread.
>> I'm blocked on deciding how to break out of the event loop so that the
>> user can at least get the command prompt back. Throwing an error in
>> linux_nat_filter_event (which is where this situation is first
>> detected) feels wrong but maybe it's ok.
>>
>
> Sorry for the followup.  "break out of the event loop" is poorly worded.  Blech.
> What I meant was of course how does one tell the event loop, in this
> particular case, that execution has stopped so gdb should take the
> terminal back (and get the command prompt back)?
> Calling error() works, modulo needing to update restore_current_thread
> to first check that the recorded current thread still exists.  Is
> there a better way?

I was wrong. :-(

Calling error() in linux_nat_filter_event doesn't work because errors
at this level are flagged as errors in talking to the target so
inferior_event_handler, case INF_REG_EVENT, will pop the target stack
down to the file stratum.

Attached is a testcase and sample session.

Attachment: hang.log.txt
Description: Text document