Re: stptracer-20060828 has released.

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

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
> chars.

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
quicker.


> [...] 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
that worth?

- FChE