One of the downsides of the fancy-schmancy expression evaluation for 
tracepoints is that it could have plain old computational errors, such 
as a divide by zero, stack underflow, invalid memory reference, etc.  
Although it's conceivable that one might somehow want tracing to 
struggle on, more likely it's a sign of a mistake in the experimental 
setup, and the right thing is to simply give up.  This patch adds 
machinery for the target to report that it stopped due to an error and 
display any available info in tstatus.

But before committing, I want to get feedback on what to do about a 
protocol mistake I made with this one; the descriptive string is 
included verbatim in the status packet, which means that it can't have 
colons embedded, and probably other characters.  There are a couple ways 
to fix - encode the string in hex, or add a length prefix.  The problem 
is that this feature has been in Ericsson's hands for awhile, bolted 
into their application already I think, and so there is a compatibility 
issue.  We do have the list of strings that their agent returns, and we 
could say for instance that a leading numeric digit is assumed to 
indicate a length field, otherwise it's handled verbatim.  On the flip 
side, this all is getting rather arcane, so maybe I'm worrying too much 
about it.  What do people think?

Stan

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

    * tracepoint.h (trace_stop_reason): Add tracepoint_error.
    (struct trace_status): New field error_desc.
    * tracepoint.c (stop_reason_names): Add terror.
    (trace_status_command): Add error report.
    (trace_status_mi): Ditto.
    (trace_save): Add special case for error description.
    (parse_trace_status): Add case for errors.

    * gdb.texinfo (Tracepoint Packets): Document trace error status.

    * gdb.trace/tfile.c: Generate an additional trace file.
    * gdb.trace/tfile.exp: Test trace file with an error stop.