[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Hi,something about the xentrace tool


  • To: "rickey berkeley" <rickey.berkeley@xxxxxxxxx>
  • From: "George Dunlap " <dunlapg@xxxxxxxxx>
  • Date: Mon, 12 Jun 2006 11:17:55 -0400
  • Cc: xen-tools@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 12 Jun 2006 08:18:20 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iVDJ8LKQ71QszSRXpOqJPNbrW4HLEn1AZNqK564WbhBzZED0hq4ADV/W24W8JNIstUn2Mv1rW2wI/49YRBgAkObcR3ygSpukg9nEcYUWqyE9w8hJoR1iM6k3ARflSxxepBPhSLmwUxsYaEE/bJDYonnaJvzD5LYHct2TZEkelM0=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Search for the "TRACE_nD" macros., where you replace 'n' with [1-5] to
see how traces are used in practice.  For example,

TRACE_2D(TRC_[sometype], dataval1, dataval2);

This will be changed by the preprocessor into

trace(TRC_[sometype], dataval1, dataval2, 0, 0, 0);

This saves us poor exhausted programmers from typing 3 extra zeros. ;-)

As you surmised, the values in the data are defined per trace value,
depending on what information the programmer writing the trace wants
to gather.

Be advised that xentrace adds the physical cpu that the event occured
on, so the real structure to read from xentrace output looks like
this:

struct trace_record {
   unsigned long cpu;
   unsigned long long tsc;
   unsigned long event;
   unsigned long data[5];
};

Peace,
-George

On 6/11/06, rickey berkeley <rickey.berkeley@xxxxxxxxx> wrote:

Hi folks:

 Recently, I am doing some research on xentrace source code.
 En,actually,I think the xentrace is a very useful tool for xen debug.

 ./xen/include/xen/trace.h
 ./xen/common/trace.c
 etc.
 I got a point very confused in the source code about the trace record.

from man page
            "Where CPU is the processor number, TSC is the record’s
timestamp  (the
            value  of the CPU cycle counter), EVENT is the event ID and
D1...D5 are
            the trace data."

            "Which correspond to the CPU number, event ID, timestamp counter
and
            the 5 data fields from the trace record.   There should be one
such
            rule for each type of event."

 So I just wonder what does these kind of D1....D5 data mean.

 I found the defined the d1-d5 structure in  xen/include/public/trace.h
 59 /* This structure represents a single trace buffer record. */
 60 struct t_rec {
 61     uint64_t cycles;          /* cycle counter timestamp */
 62     uint32_t event;           /* event ID                */
 63     unsigned long data[5];    /* event data items        */
 64 };

 and defined a trace function in ./xen/common/trace.c
 225 void trace(u32 event, unsigned long d1, unsigned long d2,
 226            unsigned long d3, unsigned long d4, unsigned long d5)
 227 {

 But I still can't understand what are these data real meaning
  I never found a place in the source code where this function void
trace(...) had been called.

 Can someone give me a clue about this?
 Or are those interfaces (d1...d5) for developers to define their own
interest to track the event?

 Your rapid reply will be appreciated.
 Thanks.

----
Regards


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.