This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: tracepoint maintainance models
- From: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- To: Vara Prasad <prasadav at us dot ibm dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Ingo Molnar <mingo at elte dot hu>, Paul Mundt <lethal at linux-sh dot org>, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, linux-kernel <linux-kernel at vger dot kernel dot org>, Jes Sorensen <jes at sgi dot com>, Andrew Morton <akpm at osdl dot org>, Tom Zanussi <zanussi at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, Michel Dagenais <michel dot dagenais at polymtl dot ca>, Christoph Hellwig <hch at infradead dot org>, Greg Kroah-Hartman <gregkh at suse dot de>, Thomas Gleixner <tglx at linutronix dot de>, William Cohen <wcohen at redhat dot com>, "Martin J. Bligh" <mbligh at mbligh dot org>, systemtap <systemtap at sourceware dot org>
- Date: Mon, 18 Sep 2006 20:49:40 +0100
- Subject: Re: tracepoint maintainance models
- 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>
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 ?