From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nommos.sslcatacombnetworking.com (nommos.sslcatacombnetworking.com [67.18.224.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id BE9FADDEDE for ; Wed, 31 Jan 2007 01:46:30 +1100 (EST) In-Reply-To: <20070130104630.GC14571@lst.de> References: <20070130104630.GC14571@lst.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C811CD0-1FA8-43AA-8D91-0C28811D021D@kernel.crashing.org> From: Kumar Gala Subject: Re: RFC: kprobes support for ppc32 Date: Tue, 30 Jan 2007 08:45:29 -0600 To: Christoph Hellwig Cc: linuxppc-dev@ozlabs.org, Paul Mackerras , prasanna@in.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Jan 30, 2007, at 4:46 AM, Christoph Hellwig wrote: > On Tue, Jan 30, 2007 at 12:13:32AM -0600, Kumar Gala wrote: >> + depends on !BOOKE && KALLSYMS && EXPERIMENTAL && MODULES > > Just curious: what's the problem with BOOKE? Book-e's debug handling/architecture is significantly different than most other PPCs. I'll look at adding support for it in the future. >> +#ifdef CONFIG_PPC64 >> regs->nip = (unsigned long)(((func_descr_t *)jp->entry)->entry); >> regs->gpr[2] = (unsigned long)(((func_descr_t *)jp->entry)->toc); >> +#else >> + regs->nip = (unsigned long)jp->entry; >> +#endif > > This should probably be split int a macro. Seems like a bit of a waste, for 6 lines of code. I'm not exactly sure what you're envisioning here. > also I think you should not define kprobe_lookup_name for the 32bit > case as the generic version should be fine for ppc32 Ok, I'll look into that. - k