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 23:38:15 -0700 Message-ID: <43670D57.8020702@hp.com> References: <4366A2B4.6070406@hp.com> <4366A81B.2050509@hp.com> <20051101061830.GB7234@granada.merseine.nu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0328550722==" Return-path: In-Reply-To: <20051101061830.GB7234@granada.merseine.nu> 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: Muli Ben-Yehuda Cc: "Magenheimer, Dan (HP Labs Fort Collins)" , Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============0328550722== Content-Type: multipart/alternative; boundary="------------050509080906020606010202" This is a multi-part message in MIME format. --------------050509080906020606010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Muli Ben-Yehuda wrote: >On Mon, Oct 31, 2005 at 04:26:19PM -0700, Rob Gardner wrote: > > >>Rob Gardner wrote: >> >> >> >>>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. ;) >>> >>> >>> >>I imagine we just need something that looks like this in trace.c: >> >>#ifdef x86 >> rdtscll(rec->cycles); >>#endif >>#ifdef IA64 >> __asm__ __volatile ("mov %0=ar.itc;;" : "=r"(rec->cycles) :: >>"memory"); >>#endif >> >> > >Can we please stick with the Linux method and put such arch dependant >ifdefs in headers and not in .c files? e.g. define a cycle_counter() >or somesuch inline function that expands to the right thing for each >arch and put it in asm-arch/... Otherwise, it gets messy very quickly >with the addition of new architectures. > > > Of course it'll be done the right way... That's why I sent out my code "suggestion" along with this comment: > Dan, perhaps you know the nice clean way of doing this sort of thing? Rob --------------050509080906020606010202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Muli Ben-Yehuda wrote: 
On Mon, Oct 31, 2005 at 04:26:19PM -0700, Rob Gardner wrote:
  
Rob Gardner wrote:

    
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. ;)

      
I imagine we just need something that looks like this in trace.c:

#ifdef x86
      rdtscll(rec->cycles);
#endif
#ifdef IA64
      __asm__ __volatile ("mov %0=ar.itc;;" : "=r"(rec->cycles) :: 
"memory");
#endif
    

Can we please stick with the Linux method and put such arch dependant
ifdefs in headers and not in .c files? e.g. define a cycle_counter()
or somesuch inline function that expands to the right thing for each
arch and put it in asm-arch/... Otherwise, it gets messy very quickly
with the addition of new architectures.

Of course it'll be done the right way... That's why I sent out my code "suggestion" along with this comment:

Dan, perhaps you know the nice clean way of doing this sort of thing?

Rob

--------------050509080906020606010202-- --===============0328550722== 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 --===============0328550722==--