Re: ERF TARGET_WAITKIND_EOF

[Andrew Cagney <ac131313 at cygnus dot com>]

BTW,

The other likely addition is ``TARGET_WAITKIND_BOGUS''.  In async mode,
target_wait() would return this when it realises that it triggered a
handle event only to later find that there actually wasn't one.

This is very different to TARGET_WAITKIND_SPURIOUS which is returned
when the target halted when it shouldn't have.  It should be continued
immediatly.

The converse to TARGET_WAITKIND_BOGUS would be TARGET_WAITKIND_TIMEOUT. 
I think that can be avoided and the returning of TIMEOUTS discouraged. 
We're ment to be moving to an event based model any way :-)

	enjoy,
		Andrew


> 
> Hello,
> 
> (I've also seen LOST, DEAD, DOA, KABOOM, KAPUT ..suggested :-).
> 
> At present when communication with a target is lost, the target
> internally indicates the falure by directly killing the target
> (mourn_inferior()) and longjmping out of there (error ()).
> 
> When it comes to async and providing clean library like behavour, having
> things randomly call error() isn't nice (besides longjmp's are bad N'kay
> ;-).
> 
> I'd like to propose the new ``enum target_waitkind'' TARGET_WAITKIND_EOF
> that target_wait() can return to indicate that the target just went
> kaput. The semantics would require the target_*() vector to post the the
> failure reason on gdb_stderr and then return TARGET_WAINTKIND_EOF.
> 
> Initially the remote async and remote extended-async targets would be
> the only ones capable of returning this result.  This would ensure that
> other non-async targets would not be affected.
> 
> Clearly this is going to stur up WFI (or what ever it is today).
> 
> I'd like comments on this and (perhaphs) someone willing to handle the
> WFI side.  I'd be willing to take care of the remote.c side.
> 
>         Andrew