From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9677 invoked by alias); 8 Jan 2010 15:21:24 -0000 Received: (qmail 9657 invoked by uid 22791); 8 Jan 2010 15:21:22 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jan 2010 15:21:17 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o08FLDxp005943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Jan 2010 10:21:14 -0500 Received: from fche.csb (vpn-231-10.phx2.redhat.com [10.3.231.10]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o08FLDM6011279; Fri, 8 Jan 2010 10:21:13 -0500 Received: by fche.csb (Postfix, from userid 2569) id 9C24D5813A; Fri, 8 Jan 2010 10:21:12 -0500 (EST) To: Prerna Saxena Cc: systemtap@sourceware.org Subject: Re: [RFC] Systemtap translator support for hw breakpoints on x86 References: <4B459CC8.2030402@linux.vnet.ibm.com> <4B474296.2000202@linux.vnet.ibm.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 08 Jan 2010 15:21:00 -0000 In-Reply-To: <4B474296.2000202@linux.vnet.ibm.com> (Prerna Saxena's message of "Fri, 08 Jan 2010 20:05:02 +0530") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q1/txt/msg00058.txt.bz2 Prerna Saxena writes: > [...] >> Instead or in addition, the translator could make the whole probe point >> type conditional on session.kernel_config("CONFIG_HAVE_HW_BREAKPOINT"). > > I'll add this in addition to the pass 4 check. Will this check take > care of cross compilation for a different kernel ? (I think it should) Yes. >>> +// Define macros for access type >>> + s.op->newline()<< "#define HWBKPT_READ 0"; >>> + s.op->newline()<< "#define HWBKPT_WRITE 1"; >>> + s.op->newline()<< "#define HWBKPT_RW 2"; >> >> (Are these necessary? Could the translator not emit symbols like >> HW_BREAKPOINT_W directly?) > > This had to be defined because some types are not defined on all > architectures. X86 supports only HW_BREAKPOINT_W and HW_BREAKPOINT_RW, > while ppc supports HW_BREAKPOINT_W and HW_BREAKPOINT_R. [...] But does this support or lack of support manifest itself in a different list of symbols defined by the kernel headers? For example, the symbol HW_BREAKPOINT_R is defined in linux/hw_breakpoint.h, so if systemtap emits code that uses it, this will compile just fine on all architectures. > [...] For now, I had designed the probes to error out if a user > defined a length that was not supported by architecture (eg a length > 3 on x86, as this supports lengths like 1,2,4 bytes only) [...] My concern with the above was not the script language interface or mappings, but only the cleanliness / simplicity of the generated code. If the translator neglects to filter out unsupported lengths, and the generated code propagates the value 3, will the kernel's registration function check and reject such requests at run time? If so, then there is no need for the generated code to contain preemptive checks / filters / error messages. Just let it listen to the result code from the kernel's registration function. As to having the translator filter for parameters expected to be valid, that is fine, but those checks need not show up redundantly in generated C code. >>> + s.op->newline()<< " rc = PTR_ERR(stap_hwbkpt_ret_array[i]);"; >>> + s.op->newline()<< " sdp->registered_p = 0;"; >>> + s.op->newline(1)<< " _stp_warn(\" Hwbkpt Probe %s : Registration error rc= %d, Addr = %p, name = %s\", probe_point, rc, addr, hwbkpt_symbol_name);"; >>> + s.op->newline(-1)<< " }"; >>> + s.op->newline()<< " else sdp->registered_p = 1;"; >>> + s.op->newline()<< "}"; >>> + s.op->newline(-1)<< "}"; // for loop >> >> Not so simple: if you get a failure on the sixth registration, you have to >> unregister the prior ones. > [...] > However, in case less resources are available at runtime (say, only 3 > out of 4 debug registers are free on x86 when the stap-generated > module is running), and the script has 4 hardware breakpoints -- the > first 3 will get registered while _only_ the 4th request will fail at > registration. I thought this was an acceptable behaviour. OK, if you want to let the registration phase pass with only partial successes, then the code must set rc = 0 around your stp_warn() call. As the code is currently, rc != 0, so the registration loop assumes that this particular derived_probe_group *has already cleaned up* any partial registrations, and will not get a subsequent call. - FChE