After going in and out of tfind mode about a thousand times in the past 
few months :-), it's become apparent that we don't want to allow 
resumption while looking at traceframes.

It often works now, to single-step the current thread while looking at a 
random trace frame, and it could probably be made to work reliably.  
However, it is incredibly confusing - for instance, after that 
single-step, are you now looking at the live thread? If so, then you 
switched yourself out of tfind mode, and your next print commands are 
displaying current state, not trace frame contents.  If instead you stay 
in tfind mode, then you have the single-step stop printing a source line 
that has nothing to do with the trace frame.  Quite likely that you just 
absent-mindedly typed "s" instead of "tfind" that you really wanted to 
go to the next frame...  Calling functions in the inferior has similar 
issues.  Sure, if you have a utility function that prettyprints a piece 
of collected data, you'd want to use it---but the function runs on the 
target using the live memory data, not the trace frame data!  And since 
the trace frame is typically incomplete, stuffing the trace frame 
contents into live memory is not going to go well... :-)

So I propose that we make an executive decision to disable all the 
resumption commands while in tfind mode.  Does this make sense to everyone?

Stan

2010-03-16 Stan Shebs  <stan@codesourcery.com>

    * infcall.c: Include tracepoint.h.
    (call_function_by_hand): Disallow calls in tfind mode.
    * infcmd.c (ensure_not_tfind_mode): New function.
    (continue_1): Call it.
    (step_1) Ditto.
    (jump_command): Ditto.
    (signal_command): Ditto.
    (until_command): Ditto.
    (finish_command): Ditto.