linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: jolsa@kernel.org, ak@linux.intel.com, namhyung@kernel.org,
	irogers@google.com, james.clark@arm.com, mpe@ellerman.id.au,
	linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	maddy@linux.vnet.ibm.com, rnsastry@linux.ibm.com,
	kjain@linux.ibm.com, disgoel@linux.ibm.com
Subject: Re: [PATCH] tools/perf: Fix usage of perf probe when libtraceevent is missing
Date: Wed, 1 Feb 2023 21:50:17 -0300	[thread overview]
Message-ID: <Y9sIyTLHssijIFLT@kernel.org> (raw)
In-Reply-To: <20230131134748.54567-1-atrajeev@linux.vnet.ibm.com>

Em Tue, Jan 31, 2023 at 07:17:48PM +0530, Athira Rajeev escreveu:
> While parsing the tracepoint events in parse_events_add_tracepoint()
> function, code checks for HAVE_LIBTRACEEVENT support. This is needed
> since libtraceevent is necessary for tracepoint. But while adding
> probe points, check for LIBTRACEEVENT is not done in case of perf probe.
> Hence, in environment with missing libtraceevent-devel, it is
> observed that adding a probe point shows below message though it
> can't be used via perf record.

Thanks, applied.

- Arnaldo

 
> Example:
> Adding probe point:
> 	./perf probe 'vfs_getname=getname_flags:72 pathname=result->name:string'
> 	Added new event:
> 	  probe:vfs_getname    (on getname_flags:72 with pathname=result->name:string)
> 
> 	You can now use it in all perf tools, such as:
> 
> 		perf record -e probe:vfs_getname -aR sleep 1
> 
> But trying perf record:
> 	./perf  record -e probe:vfs_getname -aR sleep 1
> 	event syntax error: 'probe:vfs_getname'
> 				\___ unsupported tracepoint
> 	libtraceevent is necessary for tracepoint support
> 	Run 'perf list' for a list of valid events
> 
> The builtin tool like perf record needs libtraceevent to
> parse tracefs. But still the probe can be used by enabling
> via tracefs. Patch fixes the probe usage message to the user
> based on presence of libtraceevent. With the fix,
> 
>  # ./perf probe 'pmu:myprobe=schedule'
>  Added new event:
>    pmu:myprobe          (on schedule)
> 
>  perf is not linked with libtraceevent, to use the new probe you can use tracefs:
> 
> 	cd /sys/kernel/tracing/
> 	echo 1 > events/pmu/myprobe/enable
> 	echo 1 > tracing_on
> 	cat trace_pipe
> 	Before removing the probe, echo 0 > events/pmu/myprobe/enable
> 
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
>  tools/perf/builtin-probe.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> index ed73d0b89ca2..e72f6cea76f7 100644
> --- a/tools/perf/builtin-probe.c
> +++ b/tools/perf/builtin-probe.c
> @@ -383,9 +383,18 @@ static int perf_add_probe_events(struct perf_probe_event *pevs, int npevs)
>  
>  	/* Note that it is possible to skip all events because of blacklist */
>  	if (event) {
> +#ifndef HAVE_LIBTRACEEVENT
> +		pr_info("\nperf is not linked with libtraceevent, to use the new probe you can use tracefs:\n\n");
> +		pr_info("\tcd /sys/kernel/tracing/\n");
> +		pr_info("\techo 1 > events/%s/%s/enable\n", group, event);
> +		pr_info("\techo 1 > tracing_on\n");
> +		pr_info("\tcat trace_pipe\n");
> +		pr_info("\tBefore removing the probe, echo 0 > events/%s/%s/enable\n", group, event);
> +#else
>  		/* Show how to use the event. */
>  		pr_info("\nYou can now use it in all perf tools, such as:\n\n");
>  		pr_info("\tperf record -e %s:%s -aR sleep 1\n\n", group, event);
> +#endif
>  	}
>  
>  out_cleanup:
> -- 
> 2.39.0
> 

-- 

- Arnaldo

  reply	other threads:[~2023-02-02  0:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 13:47 [PATCH] tools/perf: Fix usage of perf probe when libtraceevent is missing Athira Rajeev
2023-02-02  0:50 ` Arnaldo Carvalho de Melo [this message]
2023-02-02  4:17   ` Athira Rajeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9sIyTLHssijIFLT@kernel.org \
    --to=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.ibm.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=namhyung@kernel.org \
    --cc=rnsastry@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).