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 1/5] Refactor 'tsave'


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 (éå)


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