Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751494AbWIUTyK (ORCPT ); Thu, 21 Sep 2006 15:54:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751496AbWIUTyK (ORCPT ); Thu, 21 Sep 2006 15:54:10 -0400 Received: from gw.goop.org ([64.81.55.164]:24464 "EHLO mail.goop.org") by vger.kernel.org with ESMTP id S1751494AbWIUTyJ (ORCPT ); Thu, 21 Sep 2006 15:54:09 -0400 Message-ID: <4512EDDC.2010000@goop.org> Date: Thu, 21 Sep 2006 12:54:04 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Ingo Molnar CC: "Frank Ch. Eigler" , 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) References: <20060921160009.GA30115@Krystal> <20060921175648.GB22226@redhat.com> <20060921185029.GB12048@elte.hu> In-Reply-To: <20060921185029.GB12048@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1580 Lines: 33 Ingo Molnar wrote: > 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? Do you mean using the asm to make sure gcc puts a reference to a variable into the DWARF info, or some other way of encoding the value locations? Hm, another problem. If the mark is in a loop, and gcc decides to unroll the loop, then you'll probably only get a mark in one iteration of the loop (or 1/Nth of the iterations). Or worse, assembler errors. The only way I can see to deal with this is to not use symbols, but put records in a special section. That way, if the asm() inserting them gets duplicated, you'll get duplicate records in the marker section. I guess you'd get a similar problem with markers inserted in inlined functions. (How does gdb deal with breakpoints in unrolled loops?) J - 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/