This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Trace file support


> Date: Mon, 11 Jan 2010 18:08:20 -0800
> From: Stan Shebs <stan@codesourcery.com>
> 
> This patch adds support for trace files, which are simply dumps of a 
> target's tracepoints and trace buffer.  In addition to the new "tsave" 
> command to create a trace file, there is a new target "tfile" that opens 
> a trace file and then lets you do tfind and then print any data that was 
> collected, just as for you would do for a live target.

Thanks, I have a few comments about this part:

>     * gdb.texinfo (Trace Files): New section.
>     (Tracepoint Packets): Document QTSave and qTBuffer.

> + It is also possible to get trace data from a file, in a manner reminiscent
> + of corefiles; you specify the filename, and use @code{tfind} to search
> + through the file.  See @ref{Trace Files} for more details.
                                            ^
You need a comma here, or else makeinfo will bitch at you.  Also, "See
@ref" at the beginning of a sentence is exactly equivalent to "@xref",
so might as well use that.

> + 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 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?

> + The description section consists of multiple lines of ASCII text

@sc{ascii} will look better in print, I think.  Or try
@acronym{ASCII}.

> + Memory block. This is a contiguous block of memory, at the 8-byte
                 ^
Not enough spaces ;-)

Thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]