This is the mail archive of the
mailing list for the systemtap project.
Re: stptracer-20060828 has released.
On Fri, Sep 01, 2006 at 11:47:05AM +0800, Li Guanglei wrote:
> [...] But I have some questions about compiled approach. stap will
> treat all integer data as 64-bit, but most binary trace integer data
> items need only 1 or 2 bytes. [...] And will it use a fix length for
> all string items? Some string trace data items only have a few
The translator could apply obvious policies to this question. If the
formatting string includes "%1b", it would write just the low-order
byte of the integer. If the formatting string includes "%64s", this
would result in a fixed-width substring field. For plain "%s", it
would be a dynamic-width field, which alone would not be ideal for
binary format streams.
The idea here is to make this compiled tracing a pure optimization:
not to change the script input nor data output, but just to produce it
> [...] But in some situations I will put the print/trace statement in
> embedded c codes to avoid the calls to function__dwarf_tvar_get*.
If you don't call those tvar_get functions, how are you safely
extracting target data?
> One example is the struct scsi_cmnd in scsi trace hooks in LKET. I
> need to retrieve 10 arguments from this struct. In the embedded c
> codes they are only 10 assignments while in stap script they will be
> extended to 10 function calls.
In exchange for those function calls, you're getting safe
dereferencing of all those values. How much slowdown is