All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Ian Rogers <irogers@google.com>,
	miguel.ojeda.sandonis@gmail.com, a.hindborg@kernel.org,
	acme@kernel.org, aliceryhl@google.com, bjorn3_gh@protonmail.com,
	boqun@kernel.org, dakr@kernel.org, gary@garyguo.net,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	lossin@kernel.org, ojeda@kernel.org,
	rust-for-linux@vger.kernel.org, tmgross@umich.edu
Subject: Re: [PATCH v1] perf test type profiling: Remote typedef on struct
Date: Mon, 30 Mar 2026 23:42:25 -0700	[thread overview]
Message-ID: <acts0fXgsuirBp9G@google.com> (raw)
In-Reply-To: <kr2bfp43sqatdssmhzpmogs2h27ddbmegvaknxb6by24n2t64h@hv4m5myvswpa>

Hello,

On Sun, Mar 29, 2026 at 06:18:52PM +0200, Dmitry Dolgov wrote:
> > On Wed, Mar 04, 2026 at 11:44:16AM +0100, Dmitry Dolgov wrote:
> > > On Mon, Mar 02, 2026 at 03:58:21PM -0800, Ian Rogers wrote:
> > > The typedef creates an issue where the struct or the typedef may
> > > appear in the output and cause the "perf data type profiling tests" to
> > > fail. Let's remove the typedef to keep the test passing.
> > 
> > Yes, makes sense to me, thanks. As mentioned in the previous message, it
> > sounds fishy to me that perf record and perf mem record capture
> > different data type -- I'll try to get to the bottom of it.
> 
> I think I figured it out. To reiterate, the problem was that in my environment
> this:
> 
>     $ perf record ...
>     $ perf annotate --code-with-type ...
> 
> was showing a different data structure for workload_datasym_buf1 (buf vs struct
> _buf) than:
> 
>     $ perf mem record ...
>     $ perf annotate --code-with-type ...
> 
> It turns out that the type_die for this variable was derived differently: for
> "record" it was going through check_variable, for "mem record" through
> global_var__collect. If the type tag is DW_TAG_typedef, check_variable tries to
> figure out a real data type via die_get_real_type, which says this:
> 
>     /**
>      * [...]
>      * If the type is qualifiers (e.g. const) or typedef, this skips it
>      * and tries to find real type (structure or basic types, e.g. int).
>      */
> 
> But the underlying implementation doesn't actually check for DW_TAG_typedef for
> some reason:
> 
> 	while (tag == DW_TAG_const_type ||
> 		 tag == DW_TAG_restrict_type ||
> 		 tag == DW_TAG_volatile_type ||
> 		 tag == DW_TAG_shared_type);
> 
> By itself it doesn't look problematic, but for some reason datasym test was
> producing such a code, that had a chain of two DW_TAG_typedef in a row, so that
> die_get_real_type was returning a DW_TAG_typedef again.
> 
> It looks to me like a deficiency of die_get_real_type, and the following code
> change fixes the problem for me:
> 
> diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
> index 9267af204c7..de152fae1d9 100644
> --- a/tools/perf/util/dwarf-aux.c
> +++ b/tools/perf/util/dwarf-aux.c
> @@ -279,6 +279,7 @@ Dwarf_Die *__die_get_real_type(Dwarf_Die *vr_die, Dwarf_Die *die_mem)
>         } while (tag == DW_TAG_const_type ||
>                  tag == DW_TAG_restrict_type ||
>                  tag == DW_TAG_volatile_type ||
> +                tag == DW_TAG_typedef ||
>                  tag == DW_TAG_shared_type);
> 
>         return vr_die;
> 
> Does this change sound reasonable?

We have this:

  Dwarf_Die *die_get_real_type(Dwarf_Die *vr_die, Dwarf_Die *die_mem)
  {
      do {
          vr_die = __die_get_real_type(vr_die, die_mem);
      } while (vr_die && dwarf_tag(vr_die) == DW_TAG_typedef);
 
      return vr_die;
  }

Thanks,
Namhyung


  reply	other threads:[~2026-03-31  6:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-08 12:22 [RFC PATCH v2 0/4] Test annotate with data type profiling Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 1/4] tools/build: Add a feature test for rust compiler Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload Dmitrii Dolgov
2026-02-09 17:29   ` Ian Rogers
2026-02-11 10:57     ` Dmitry Dolgov
2026-02-09 17:33   ` Ian Rogers
2026-02-11 10:02     ` Dmitry Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 3/4] perf tests: Test annotate with data type profiling and rust Dmitrii Dolgov
2026-02-08 12:22 ` [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C Dmitrii Dolgov
2026-02-10  5:39   ` Ian Rogers
2026-02-10 11:57     ` Dmitry Dolgov
2026-03-02 23:58       ` [PATCH v1] perf test type profiling: Remote typedef on struct Ian Rogers
2026-03-04 10:44         ` Dmitry Dolgov
2026-03-04 20:34           ` Arnaldo Carvalho de Melo
2026-03-29 16:18           ` Dmitry Dolgov
2026-03-31  6:42             ` Namhyung Kim [this message]
2026-03-31 19:22               ` Dmitry Dolgov
2026-04-14 14:16                 ` Dmitry Dolgov
2026-04-14 14:42                 ` Gary Guo
2026-04-14 16:08                   ` Dmitry Dolgov
2026-03-04 21:48         ` Namhyung Kim
2026-03-04 22:04           ` Arnaldo Carvalho de Melo
2026-02-08 14:39 ` [RFC PATCH v2 0/4] Test annotate with data type profiling Arnaldo Carvalho de Melo
2026-02-08 14:42   ` Rust data-type profiling working in perf was: " Arnaldo Carvalho de Melo
2026-02-08 15:16     ` Miguel Ojeda
2026-02-09  8:45     ` Dmitry Dolgov
2026-02-10  1:26       ` Namhyung Kim

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=acts0fXgsuirBp9G@google.com \
    --to=namhyung@kernel.org \
    --cc=9erthalion6@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=acme@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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.