Re: [PATCH 1/5] Refactor 'tsave'

[Yao Qi <yao@codesourcery.com>]

On 03/01/2013 06:05 PM, Pedro Alves wrote:
> And what is the format of that "raw" data?  Exactly the format

"raw data" doesn't mean format-less data.  The format here is how data 
are organized in trace *buffer*.  Data stored in trace buffer are 
treated as "raw".

> described in the manual, in the "Trace File Format" node:
>
> "The trace frame section consists of a number of consecutive frames.
> Each frame begins with a two-byte tracepoint number, followed by a
> four-byte size giving the amount of data in the frame.  The data in
> the frame consists of a number of blocks, each introduced by a
> character indicating its type (at least register, memory, and trace
> state variable).  The data in this section is raw binary, not a
> hexadecimal or other encoding; its endianness matches the target's
> endianness."

Yes, this is only about TFILE format, instead of how data are stored in 
trace buffer, which is GDB internal.

>
> So it's not really "raw" binary data -- there's a format, with
> headers and all.  And it can't be any other format, otherwise
> the patch's design won't work... (**)
>

I never say "raw data is binary data or raw data is format-less data".
My point is raw data has its own format, and GDB is free to store them
directly by write_raw_data or parse them (according to how data are 
stored in trace buffers) first and store them in some
format (CTF and even TFILE).

>> >
>> >TFILE is a format that composed by ascii definition part and trace frames dumped from the raw data directly.  There could be another trace file format FOO that stores raw data as well.
> It's not "raw".  It's trace frames in gdb's trace file format
> as defined in the manual.
>

It is just because TFILE format use the same format that data are
stored in trace buffers.  One day, we can use another way to organize
the trace buffers, but still output TFILE format in default.  For 
example, we may add checksum for each block in trace buffers in 
GDBserver in the future, but still generate TFILE format trace file in 
GDB side.  When we get raw data (with checksum in each block) from the 
remote target, can we call them "tfile format data"?.  Another example 
is GDBserver can send the format of trace buffers to GDB first via xml, 
and GDB can parse the data got from GDBserver according the xml 
description, and save them into CTF or TFILE format.  We can't call the 
data from the remote target "tfile format data".

>> >
>>>>> >>> >+    {
>>>>> >>> >+      uint16_t tp_num;
>>>>> >>> >+      uint32_t tf_size;
>>>>> >>> >+      unsigned int read_length;
>>>>> >>> >+      unsigned int block;
>>>>> >>> >+
>>>>> >>> >+      /* Read the first six bytes in, which is the tracepoint
>>>>> >>> >+         number and trace frame size.  */
>>>>> >>> >+      gotten = target_get_raw_trace_data (buf, offset, 6);
>>>>> >>> >+
>>>>> >>> >+      if (gotten == 0)
>>>>> >>> >+        break;
>>>>> >>> >+      tp_num = (uint16_t)
>>>>> >>> >+        extract_unsigned_integer (&buf[0], 2, byte_order);
>>>>> >>> >+
>>>>> >>> >+      tf_size = (uint32_t)
>>>>> >>> >+        extract_unsigned_integer (&buf[2], 4, byte_order);
> (**) ... as can be seen here and below with
>
> +		  switch (block_type)
> +		    {
> +		    case 'R':
> ...
> +		    case 'M':
> ...
>
> etc.
>
> This is parsing the "raw"'s headers, in gdb's trace file format.
> This as the else branch.  The "then" branch only works if the target
> can interpret "buf" as trace frames in gdb's trace file format.
>
Again, it is not trace file format.  It is how data are stored in trace 
buffers.

-- 
Yao (齐尧)