From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Gardner Subject: Re: Recent trace patch not arch-neutral Date: Mon, 31 Oct 2005 16:03:16 -0700 Message-ID: <4366A2B4.6070406@hp.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0692945029==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: "Magenheimer, Dan (HP Labs Fort Collins)" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============0692945029== Content-Type: multipart/alternative; boundary="------------000401020101050709080305" This is a multi-part message in MIME format. --------------000401020101050709080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Pratt wrote: >>A recent patch to trace.c uses a call to rdtscll() which is >>x86-specific. Is there an arch-neutral call that can be used >>instead? Or do arch's need to implement this? (And if the >>latter, should we choose a more generic name?) >> >> > >The tracebuffer code has always used the cycle counter, so if you've >previously been compiling it for ia64 it must have previously been using >some more arch neutral way of accessing it... > > The deal with this is that the default was always trace=n so the trace macros never expanded to anything unless you wanted them to. One of the things that Keir did in "cleaning up" my code was to totally eliminate all conditional compilation. That's why this problem is suddenly showing up on ia64. Now, to answer Dan's question- the rdtscll thing is just a time stamp counter, expressed in cycles. So on ia64 you could probably replace it with an asm statement to read ar.itc to make everything work. We just need a little wrapper to do the right thing for each architecture. Now Dan, if you were more conveniently located, perhaps we could work together and fix this. ;) Rob Rob --------------000401020101050709080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian Pratt wrote: 
A recent patch to trace.c uses a call to rdtscll() which is 
x86-specific.  Is there an arch-neutral call that can be used 
instead?  Or do arch's need to implement this?  (And if the 
latter, should we choose a more generic name?)
    

The tracebuffer code has always used the cycle counter, so if you've
previously been compiling it for ia64 it must have previously been using
some more arch neutral way of accessing it...


The deal with this is that the default was always trace=n so the trace macros never expanded to anything unless you wanted them to. One of the things that Keir did in "cleaning up" my code was to totally eliminate all conditional compilation. That's why this problem is suddenly showing up on ia64.

Now, to answer Dan's question- the rdtscll thing is just a time stamp counter, expressed in cycles. So on ia64 you could probably replace it with an asm statement to read ar.itc to make everything work. We just need a little wrapper to do the right thing for each architecture. Now Dan, if you were more conveniently located, perhaps we could work together and fix this. ;)

Rob


Rob

--------------000401020101050709080305-- --===============0692945029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0692945029==--