From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-4210-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 25112 invoked by alias); 18 Sep 2006 19:26:33 -0000
Received: (qmail 25098 invoked by uid 22791); 18 Sep 2006 19:26:32 -0000
X-Spam-Status: No, hits=-0.8 required=5.0 	tests=AWL,BAYES_00,FORGED_RCVD_HELO,UNPARSEABLE_RELAY
X-Spam-Check-By: sourceware.org
Received: from outpipe-village-512-1.bc.nu (HELO lxorguk.ukuu.org.uk) (81.2.110.250)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Sep 2006 19:26:22 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) 	by lxorguk.ukuu.org.uk (8.13.6/8.13.4) with ESMTP id k8IJngGc026538; 	Mon, 18 Sep 2006 20:49:42 +0100
Received: (from alan@localhost) 	by localhost.localdomain (8.13.6/8.13.6/Submit) id k8IJnf3V026536; 	Mon, 18 Sep 2006 20:49:41 +0100
X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: tracepoint maintainance models
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Vara Prasad <prasadav@us.ibm.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, Ingo Molnar <mingo@elte.hu>,         Paul Mundt <lethal@linux-sh.org>,         Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,         linux-kernel <linux-kernel@vger.kernel.org>,         Jes Sorensen <jes@sgi.com>, Andrew Morton <akpm@osdl.org>,         Tom Zanussi <zanussi@us.ibm.com>,         Richard J Moore <richardj_moore@uk.ibm.com>,         Michel Dagenais <michel.dagenais@polymtl.ca>,         Christoph Hellwig <hch@infradead.org>,         Greg Kroah-Hartman <gregkh@suse.de>,         Thomas Gleixner <tglx@linutronix.de>,         William Cohen <wcohen@redhat.com>,         "Martin J. Bligh" <mbligh@mbligh.org>,         systemtap <systemtap@sourceware.org>
In-Reply-To: <450EEF2E.3090302@us.ibm.com>
References: <20060917143623.GB15534@elte.hu> 	 <20060917153633.GA29987@Krystal> <20060918000703.GA22752@elte.hu> 	 <450DF28E.3050101@opersys.com> <20060918011352.GB30835@elte.hu> 	 <20060918122527.GC3951@redhat.com> <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>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 18 Sep 2006 19:26:00 -0000
Message-Id: <1158608981.6069.167.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5)
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
X-SW-Source: 2006-q3/txt/msg00547.txt.bz2

Ar Llu, 2006-09-18 am 12:10 -0700, ysgrifennodd Vara Prasad:
> I am not sure i quiet understand your line number part of the proposal. 
> Does this proposal assume we have access to source code while generating 
> dynamic probes?

Its one route - or we dump it into an ELF section in the binary.

> This still doesn't solve the problem of compiler optimizing such that a 
> variable i would like to read in my probe not being available at the 
> probe point.

Then what we really need by the sound of it is enough gcc smarts to do
something of the form

	.section "debugbits"
	
	.asciiz 'hook_sched'
	.dword l1	# Address to probe
	.word 1		# Argument count
	.dword gcc_magic_whatregister("next"); [ reg num or memory ]
	.dword gcc_magic_whataddress("next"); [ address if exists]


Can gcc do any of that for us today ?