[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5564B279.2090809@plumgrid.com>
Date: Tue, 26 May 2015 10:50:49 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: He Kuang <hekuang@...wei.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
wangnan0@...wei.com, paulus@...ba.org, a.p.zijlstra@...llo.nl,
mingo@...hat.com, acme@...nel.org, namhyung@...nel.org,
jolsa@...nel.org, dsahern@...il.com, brendan.d.gregg@...il.com,
daniel@...earbox.net
CC: lizefan@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists