Re: [PATCH] Trace file support

[Stan Shebs <stan at codesourcery dot com>]

Eli Zaretskii wrote:
> > + then save it.  If the target supports it, you can also supply the
> > + optional argument @code{-r} (``remote'') to direct the target to save
> > + the data directly into @var{filename} in its filesystem, which may be
> > + more efficient if the trace buffer is very large.
> > + 
> > + @kindex target tfile
> > + @kindex tfile
> > + @item target tfile @var{filename}
> > + Use the given @var{filename} as a source of trace data.
> >     
>
> This leaves me wondering: how would "target tfile" know whether to
> look on the host or on the target for the specified file?  How about
> clarifying that?
>
>   
The tfile target is mutually exclusive with target remote, when you read 
from it there is no remote target in the picture.  But juxtaposed with 
the options for local/remote creation, just above, there is certainly 
potential for confusion.
> > + The trace file comes in three parts: a header, a textual description
> > + section, and a trace frame section with binary data. [...]
> >     
>
> I wonder if we really need such a detailed description of the file's
> format in the user manual.  Who would need that? can we simply send
> the interested reader to some header file?
>   
Good point - if one uses GDB to both create a trace file and read from 
it, then it's effectively a private format.  There is the case of the 
target agent writing the file directly, but I expect that will be less 
common.  On the other hand, if a target stub/agent does write trace 
files, then we should make some degree of stability promise (could one 
get compiled into Linux kernel?), and the GDB manual is our main avenue 
for describing that promise.  If we went the header file route, then 
there is a license issue for the file too.

Stan