On 03/01/2013 06:05 PM, Pedro Alves wrote:
> Ugh.  Why do we have this limitation at all?
> target_get_raw_trace_data works with an offset and size, so
> I don't even see why we need to fetch the whole trace frame
> in one go.
>

We can get the a fixed-length of data from the target, but we have face 
the problem that a block may be broken into two pieces.  So we have to 
check the boundary, shift contents in buf, and fetch more data to 
complete the block.  This makes the code hard to read and maintain. 
Finally, I decide to fetch data on a block level.  That is, fetch one 
byte first to determine the type, and then fetch the block as a whole. 
M block is an exception here, because it can be very large, so I split 
the API to write M block into two (for header and content respectively, 
see more in the comments of this patch).  In this way, GDB has more 
round-trip with the target to get trace buffer data, but the code is 
clean and able to handle large M block.  I tested it by setting 
MAX_TRACE_UPLOAD to 450, and cause multiple fetches to finish the whole 
M block.  It works well.

>> >
>>>>> >>> >+        }
>>>>> >>> >+
>
>>>>> >>> >+  /* Write to mark the definition part is end.  */
>>> >>This doesn't parse correctly.  Something like:
>>> >>
>>> >>    /* Called to signal the end of the definition part.  */
>>> >>
>>> >>perhaps.
>>> >>
>> >
>> >Is it incorrect?
> I think so.
>
>> >The basic sentence pattern is "write (an intransitive verb) to do sth.", and "[that] the definition part is end" is a noun clause.
> "to signal" is not intransitive.  But I don't think an
> intransitive verb is what you wanted anyway.
>
> "is end" isn't correct.
>
> "is over", or "is done" or "is/has finished" or "has ended"
> would be good.  By my order of preference:
>
>   "Write to mark the end of the definition part."

I choose this one.

-- 
Yao (齐尧)