Re: stptracer-20060828 has released.

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

Hi Frank,

Frank Ch. Eigler wrote:
> Li Guanglei <guanglei@cn.ibm.com> writes:
> 
>> [...]  So we use _stp_printf() for its fancy printing format in
>> trade of its slower speed compared with gBTI.  But the interface
>> like gBTI imposes too much restriction on trace data format and the
>> number of data items to be traced. Maybe we should find some places
>> inside _stp_printf() for further performance improvement while still
>> have the capability to print data freely.
> 
> To avoid the overhead inherent in dynamic interpretation of formatting
> strings, we would need to gradually adopt a compiled approach.  The
> translator is already parsing formatting strings.  It could emit
> low-level equivalent code to write binary chunks directly.  The
> runtime would only need to provide buffer-reservation/commit routines.

It's a good idea.
I suggest that the stpd should handle each binary chunks correctly.

In the gBTI approach, each binary data has its length information in
the head of the entry. So the enhanced merging routine (gbti_merge
command) can separate those entries correctly even if the routine
doesn't know the format of the binary data.

Current systemtap can't merge the temporary files which include
binary data correctly. I think if each binary chunks has its
length information, we can merge them correctly.

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com