From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752825AbbE0LnM (ORCPT ); Wed, 27 May 2015 07:43:12 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]:55390 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752518AbbE0LnK (ORCPT ); Wed, 27 May 2015 07:43:10 -0400 Message-ID: <5565ADC6.9070407@hitachi.com> Date: Wed, 27 May 2015 20:43:02 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: He Kuang , Alexei Starovoitov , wangnan0@huawei.com, paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com, acme@kernel.org, namhyung@kernel.org, jolsa@kernel.org, dsahern@gmail.com, brendan.d.gregg@gmail.com, daniel@iogearbox.net CC: lizefan@huawei.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo References: <1432456091-73384-1-git-send-email-hekuang@huawei.com> <1432456091-73384-10-git-send-email-hekuang@huawei.com> <556190AA.10406@hitachi.com> <5562DE44.4010601@huawei.com> <5564B279.2090809@plumgrid.com> <55652B7B.2040409@huawei.com> In-Reply-To: <55652B7B.2040409@huawei.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/05/27 11:27, He Kuang wrote: > hi, Alexei > > On 2015/5/27 1:50, Alexei Starovoitov wrote: >> On 5/25/15 1:33 AM, He Kuang wrote: >>> Right, I learnt regparm(3) is mandatory in x86_32, according to rules, >>> the first three args will go to regparm(ax, dx, cx). But we should not >>> refer arg1~3 to ax, dx, cx because of 64bit parameters (other reasons?). >>> >>> Consider this keyword is used for generating bpf prologue which fetches >>> formal parameters when no debuginfo is provided, for this purpose, we can: >>> 1) We just help fetch the $regs or $regparms(If the keyword is >>> $regparms, ax/dx/cx is fetched, nothing related to args) to bpf arglists >>> and leave the rest things to bpf prog writer. >>> >>> 2) Keep that on platforms like x86_64 and skip this feature on >>> platforms like x86_32. >>> >>> or any other suggestions? >> >> Single argument like $regparam or whatever name cannot work on all >> architectures, that's why in the very beginning I suggested >> 'func(long, char, void*)' syntax to describe arguments when debuginfo >> is not available. Calling convention for scalars is simple enough on >> all major architectures. x64_64 - trivial, i64_32 - a bit more involved, >> but simple enough so that list of types of arguments is enough to figure >> out which register or register pair or stack should be used to fetch >> argN. >> >> > As Masami has reminded, the use of 'asmlinkage' forces regparm=0, and > we can't destinguish them without debuginfo, so 'func(long, char, > void*)' syntax not work in everywhere. > > In fact, all the context infos are there in bpf prog(pt_regs in arg1). > To the non-debuginfo case, without the help of prologue, user steps > following flow to fetch params: > > 1. pt_regs(arg1) + architecture => calling regs > > 2. calling regs + function prototype(SEC) + gcc attributes(like > asmlinkage) => formal parameters > > '$regparms' do the 1st step, though not a full workaround. But for the > lack of gcc attributes, it seems we can't do the 2nd step. Any ideas? If you don't have the debuginfo, $regparams will help, but not cover all the cases. This just means users may need to take care of using it. Actually, in most cases, I'm sure $regparams will work fine, since most functions are not asmlinkage'ed. If you consider bpf requires correct parameters, you need debuginfo or something like it, e.g. the pre-analyzed cache of perf-probe (see https://lkml.org/lkml/2014/10/31/207). Thank you, -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: masami.hiramatsu.pt@hitachi.com