From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933306AbcDKNpY (ORCPT ); Mon, 11 Apr 2016 09:45:24 -0400 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:43109 "EHLO e23smtp07.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932456AbcDKNpT (ORCPT ); Mon, 11 Apr 2016 09:45:19 -0400 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: naveen.n.rao@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 11 Apr 2016 19:13:26 +0530 From: "Naveen N. Rao" To: Michael Ellerman , Arnaldo Carvalho de Melo Cc: Balbir Singh , linux-kernel@vger.kernel.org, Mark Wielaard , Masami Hiramatsu , Thiago Jung Bauermann , linuxppc-dev@lists.ozlabs.org, Ananth N Mavinakayanahalli Subject: Re: [PATCH 0/2] perf probe fixes for ppc64le Message-ID: <20160411134325.GM15993@naverao1-tp.in.ibm.com> References: <57061802.7020508@gmail.com> <20160407092636.GK15993@naverao1-tp.in.ibm.com> <1460098663.6475.6.camel@gmail.com> <20160409134239.GL15993@naverao1-tp.in.ibm.com> <1460349706.3444.2.camel@ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1460349706.3444.2.camel@ellerman.id.au> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16041113-0025-0000-0000-0000043E8104 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/04/11 02:41PM, Michael Ellerman wrote: > On Sat, 2016-04-09 at 19:12 +0530, Naveen N. Rao wrote: > > > > I suppose this boils down to the quirkiness of ABIv2. Though, in > > reality, I don't think most users will notice. As I stated above, users > > will most likely start with the disassembly or debuginfo and this patch > > ensures there are actually no surprises there. > > Yeah it's unfortunate that we have to handle these two cases differently. > > But I think you've chosen the right trade off. > > When we are just given the name we *must not* use the global entry point, > otherwise the probes will often not hit - because most calls go to the local > entry point and skip the global entry point entirely. > > When we're given a name and offset, it's less confusing if we use the global > entry point as the base for the offset calculation. > > So for the concept: > > Acked-by: Michael Ellerman Thanks, Michael. That helps. > > I don't really know this part of the perf code enough to give you an ack for the > actual changes, I'll leave that to the perf maintainers. Sure. Arnaldo, I will send a v2 soon with a bit more testing to make sure this covers all scenarios properly (I am also trying to see if we can address debuginfo-based probing properly). - Naveen