(2014/02/26 18:03), Hemant Kumar wrote:
On 02/26/2014 01:48 PM, Namhyung Kim wrote:No, here what I said is, the "perf sdt" is only for managing SDT cache
Hi Masami and Hemant,
On Tue, 25 Feb 2014 21:27:07 +0530, Hemant Kumar wrote:
On 02/25/2014 05:14 PM, Masami Hiramatsu wrote:What should be done with the new perf sdt command? If it's only
(2014/02/24 18:14), Hemant Kumar wrote:Hmm, this seems a better idea :)
First, scan the binaries using :Hmm, in that case, I think you'd better introduce perf-sdt for scanning.
# perf list sdt --scan
Creating a cache of SDT markers...
perf sdt cache created!
Use : "perf list sdt"
to see the SDT markers
e.g.
# perf sdt --scan app
then you can add app to sdt cache, without app,
# perf sdt --scan
will just scans all binaries on the PATH and the libraries which listed
by `ldconfig --print-caceh`
intended to list the markers, I'd just suggest to add "perf list sdt" as
this patch did.
as like as "perf buildid-cache". Thus, "perf sdt-cache" might be better.
BTW, the SDT markers can be changed if the application is updated.
To ensure the correctness of SDT markers, we should store buildid in the
cache file and check it when listing and using them.
If we display the SDT markers along with the other events in perf list,As I said, if perf accepts -e "%app:sdt" option, showing SDT events as
then I think we can go with
perf list sdt. I am not too sure though! :)
For me, the main issue was that the markers are not events. They become
events after
we place them in the uprobe_events file just like functions. But we use
`perf list` to
display all the "events" available on a system. Isn't it?
fixed events does not matter, since it is transparent to users. :)
Thank you,