Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751466AbWIUS7G (ORCPT ); Thu, 21 Sep 2006 14:59:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751465AbWIUS7G (ORCPT ); Thu, 21 Sep 2006 14:59:06 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:25573 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1751466AbWIUS7F (ORCPT ); Thu, 21 Sep 2006 14:59:05 -0400 Date: Thu, 21 Sep 2006 20:50:29 +0200 From: Ingo Molnar To: "Frank Ch. Eigler" Cc: Mathieu Desnoyers , Martin Bligh , Masami Hiramatsu , prasanna@in.ibm.com, Andrew Morton , Mathieu Desnoyers , Paul Mundt , linux-kernel , Jes Sorensen , Tom Zanussi , Richard J Moore , Michel Dagenais , Christoph Hellwig , Greg Kroah-Hartman , Thomas Gleixner , William Cohen , ltt-dev@shafik.org, systemtap@sources.redhat.com, Alan Cox Subject: Re: [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe management) Message-ID: <20060921185029.GB12048@elte.hu> References: <20060921160009.GA30115@Krystal> <20060921175648.GB22226@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060921175648.GB22226@redhat.com> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -2.9 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.9 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.4999] -0.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1359 Lines: 29 * Frank Ch. Eigler wrote: > > +#define MARK_SYM(name) \ > > + here: asm volatile \ > > + (MARK_KPROBE_PREFIX#name " = %0" : : "m" (*&&here)); \ > > Regarding MARK_SYM, if I read Ingo's message correctly, this is the > only type of marker he believes is necessary, since it would put a > place for kprobes to put a breakpoint. FWIW, this still appears to be > applicable only if the int3 overheads are tolerable, and if parameter > data extraction is unnecessary or sufficiently robust "by accident". let me qualify that: parameters must be prepared there too - but no actual function call inserted. (at most a NOP inserted). The register filling doesnt even have to be function-calling-convention compliant - that makes the symbolic probe almost zero-impact to register allocation/scheduling, the only thing it should ensure is that the parameters that are annotated to be available in register, stack or memory _somewhere_. (i.e. not hidden or destroyed at that point by gcc) Does a simple asm() that takes read-only parameters but only adds a NOP achieve this result? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/