From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2313 invoked by alias); 6 Oct 2006 14:23:46 -0000 Received: (qmail 2305 invoked by uid 22791); 6 Oct 2006 14:23:45 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from ms-smtp-01.nyroc.rr.com (HELO ms-smtp-01.nyroc.rr.com) (24.24.2.55) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Oct 2006 14:23:37 +0000 Received: from [192.168.23.10] (cpe-24-94-51-176.stny.res.rr.com [24.94.51.176]) by ms-smtp-01.nyroc.rr.com (8.13.6/8.13.6) with ESMTP id k96ENJX1029208; Fri, 6 Oct 2006 10:23:20 -0400 (EDT) Date: Fri, 06 Oct 2006 14:23:00 -0000 From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: "Frank Ch. Eigler" cc: Vara Prasad , Alan Cox , Ingo Molnar , Paul Mundt , Mathieu Desnoyers , linux-kernel , Jes Sorensen , Andrew Morton , Tom Zanussi , Richard J Moore , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , "Martin J. Bligh" , systemtap Subject: Re: tracepoint maintainance models In-Reply-To: <20061006130156.GA3566@redhat.com> Message-ID: References: <20060918150231.GA8197@elte.hu> <1158594491.6069.125.camel@localhost.localdomain> <20060918152230.GA12631@elte.hu> <1158596341.6069.130.camel@localhost.localdomain> <20060918161526.GL3951@redhat.com> <1158598927.6069.141.camel@localhost.localdomain> <450EEF2E.3090302@us.ibm.com> <1158608981.6069.167.camel@localhost.localdomain> <450F0180.1040606@us.ibm.com> <1160112791.30146.12.camel@localhost.localdomain> <20061006130156.GA3566@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: Symantec AntiVirus Scan Engine Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00038.txt.bz2 On Fri, 6 Oct 2006, Frank Ch. Eigler wrote: > Hi - > > On Fri, Oct 06, 2006 at 01:33:11AM -0400, Steven Rostedt wrote: > > Coming into this really late, and I'm still behind in reading this and > > related threads, but I want to throw this idea out, and it's getting > > late. > > [...] > > #define MARK(label, var) \ > > asm ("debug_" #label ":\n" \ > > ".section .data\n" \ > > #label "_" #var ": xor %0,%0\n" \ > > ".previous" : : "r"(var)) > > [...] > > $ gcc -O2 -o mark mark.c > > $ ./mark > > func y is in reg B at 0x80483ce > > [...] > > Clever. > > > Now the question is, isn't MARK() in this code a non intrusive marker? > > Not quite. The assembly code forces gcc to materialize the data that > it might already have inlined, and to borrow a register for the > duration. It's still a neat idea though. Thanks! You're right, it is intrusive in a way that it does modify the way gcc can optimize that section of code. But what I like about this idea, is that it allows for us to tell gcc that we want this variable inside a register, and then gcc can do that for us and still optimize around that. We put no more constraints on the code, except that we want some value in a register at some given point of execution. This should only be done for local variables that are not easily captured in a probe. Of course with i386's limit on registers, it can put a little strain if we want more than one variable. But x86_64 will soon be the norm, and the added registers should help out a lot. -- Steve