All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Leo Yan <leo.yan@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	James Clark <james.clark@linaro.org>,
	Mike Leach <mike.leach@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"Liang, Kan" <kan.liang@linux.intel.com>,
	Will Deacon <will@kernel.org>,
	"Graham Woodward" <graham.woodward@arm.com>,
	<Paschalis.Mpeis@arm.com>, <linux-perf-users@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 01/12] perf script: Make printing flags reliable
Date: Mon, 3 Mar 2025 17:05:13 +0200	[thread overview]
Message-ID: <447bcafc-4c47-4b95-bf21-7aee2cb6a629@intel.com> (raw)
In-Reply-To: <20250303162210.GH2157064@e132581.arm.com>

On 3/03/25 18:22, Leo Yan wrote:
> Hi Adrian,
> 
> On Mon, Mar 03, 2025 at 12:44:33PM +0200, Adrian Hunter wrote:
>> On 17/02/25 21:58, Leo Yan wrote:
>>> Add a check for the generated string of flags.  Print out the raw number
>>> if the string generation fails.
>>
>> How does it fail?
> 
> In practice, I agreed perf_sample__sprintf_flags() will not fail.  This
> bases on a careful calculation for every invoking snprintf().
> 
> Please see comment below.
> 
>>> In another case, if the string length is longer than the aligned size,
>>> allow the completed string to be printed.
>>>
>>> Reviewed-by: Ian Rogers <irogers@google.com>
>>> Reviewed-by: James Clark <james.clark@linaro.org>
>>> Signed-off-by: Leo Yan <leo.yan@arm.com>
>>> ---
>>>  tools/perf/builtin-script.c   | 10 ++++++++--
>>>  tools/perf/util/trace-event.h |  2 ++
>>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>>> index d797cec4f054..2c4b1fb7dc72 100644
>>> --- a/tools/perf/builtin-script.c
>>> +++ b/tools/perf/builtin-script.c
>>> @@ -1709,9 +1709,15 @@ static int perf_sample__fprintf_bts(struct perf_sample *sample,
>>>  static int perf_sample__fprintf_flags(u32 flags, FILE *fp)
>>>  {
>>>  	char str[SAMPLE_FLAGS_BUF_SIZE];
>>> +	int ret;
>>> +
>>> +	ret = perf_sample__sprintf_flags(flags, str, sizeof(str));
>>> +	if (ret < 0)
>>
>> AFAICT ret is always >= 0
> 
> Since I refactored perf_sample__sprintf_flags() in the sequential
> patches, for easier capturing and debugging, here checks the return
> value to detect any potential issues.
> 
> Later when we review a perf log, a printed raw number for error cases
> can remind there must be something wrong for printing flags.
> 
>>> +		return fprintf(fp, "  raw flags:0x%-*x ",
>>> +			       SAMPLE_FLAGS_STR_ALIGNED_SIZE - 12, flags);
>>>  
>>> -	perf_sample__sprintf_flags(flags, str, sizeof(str));
>>> -	return fprintf(fp, "  %-21s ", str);
>>> +	ret = max(ret, SAMPLE_FLAGS_STR_ALIGNED_SIZE);
>>> +	return fprintf(fp, "  %-*s ", ret, str);
>>
>> -21 means the field width is 21 and left-justified.  It should not
>> truncate the string.
> 
> No, it does not truncate the string.
> 
> It calculates a maximum value between the returned length and 21 (
> defined in SAMPLE_FLAGS_STR_ALIGNED_SIZE).  It keeps left-justified and
> can printing a complete string if the string length is bigger than 21.

Maybe I am missing something, but that isn't that what

	return fprintf(fp, "  %-21s ", str);

does anyway?  Why change it to something more complicated.

> 
> 
>>
>>>  }
>>>  
>>>  struct printer_data {
>>> diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
>>> index ac9fde2f980c..71e680bc3d4b 100644
>>> --- a/tools/perf/util/trace-event.h
>>> +++ b/tools/perf/util/trace-event.h
>>> @@ -145,6 +145,8 @@ int common_flags(struct scripting_context *context);
>>>  int common_lock_depth(struct scripting_context *context);
>>>  
>>>  #define SAMPLE_FLAGS_BUF_SIZE 64
>>> +#define SAMPLE_FLAGS_STR_ALIGNED_SIZE	21
>>> +
>>>  int perf_sample__sprintf_flags(u32 flags, char *str, size_t sz);
>>>  
>>>  #if defined(LIBTRACEEVENT_VERSION) &&  LIBTRACEEVENT_VERSION >= MAKE_LIBTRACEEVENT_VERSION(1, 5, 0)
>>



  reply	other threads:[~2025-03-03 16:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 19:58 [PATCH v3 00/12] perf script: Refactor branch flags for Arm SPE Leo Yan
2025-02-17 19:58 ` [PATCH v3 01/12] perf script: Make printing flags reliable Leo Yan
2025-03-03 10:44   ` Adrian Hunter
2025-03-03 16:22     ` Leo Yan
2025-03-03 15:05       ` Adrian Hunter [this message]
2025-03-03 18:11         ` Leo Yan
2025-03-03 16:56           ` Adrian Hunter
2025-03-03 18:49             ` Leo Yan
2025-02-17 19:58 ` [PATCH v3 02/12] perf script: Refactor sample_flags_to_name() function Leo Yan
2025-02-17 19:58 ` [PATCH v3 03/12] perf script: Separate events from branch types Leo Yan
2025-02-17 19:59 ` [PATCH v3 04/12] perf script: Add not taken event for branches Leo Yan
2025-02-17 19:59 ` [PATCH v3 05/12] perf script: Add not taken event for branch stack Leo Yan
2025-02-17 19:59 ` [PATCH v3 06/12] perf arm-spe: Fix load-store operation checking Leo Yan
2025-02-26 13:33   ` James Clark
2025-02-17 19:59 ` [PATCH v3 07/12] perf arm-spe: Extend branch operations Leo Yan
2025-02-17 19:59 ` [PATCH v3 08/12] perf arm-spe: Decode transactional event Leo Yan
2025-02-17 19:59 ` [PATCH v3 09/12] perf arm-spe: Fill branch operations and events to record Leo Yan
2025-02-17 19:59 ` [PATCH v3 10/12] perf arm-spe: Set sample flags with supplement info Leo Yan
2025-02-17 19:59 ` [PATCH v3 11/12] perf arm-spe: Add branch stack Leo Yan
2025-02-17 19:59 ` [PATCH v3 12/12] perf arm-spe: Support previous branch target (PBT) address Leo Yan
2025-03-03  9:38 ` [PATCH v3 00/12] perf script: Refactor branch flags for Arm SPE Leo Yan
2025-03-03 21:00   ` Namhyung Kim
2025-03-04 11:33     ` Leo Yan
2025-03-04 18:43       ` Namhyung Kim
2025-03-05  9:53         ` Leo Yan

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=447bcafc-4c47-4b95-bf21-7aee2cb6a629@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=Paschalis.Mpeis@arm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=graham.woodward@arm.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=namhyung@kernel.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.