Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yanbo Zhao" <yzhao62@ncsu.edu>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v4 3/3] perf annotate: Resolve C++ virtual function calls in x86 insn tracking
Date: Tue, 03 Nov 2026 16:40:45 +0000	[thread overview]
Message-ID: <sashiko-outbox-195734@kernel.org> (raw)
In-Reply-To: <20261103155650.269973-4-yzhao62@ncsu.edu>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf dwarf-aux: unbounded recursion in __die_find_member_offset_cb()
--

commit e681ce13b22214a8ffd9b0e9b51a57f0b2937bb7
Author: Yanbo Zhao <yzhao62@ncsu.edu>

perf annotate: Resolve C++ virtual function calls in x86 insn tracking

This commit resolves C++ virtual function calls during x86 instruction
state tracking by tracking vtable pointer loads and virtual function
pointer calls using DWARF vtable helpers.

> diff --git a/tools/perf/util/annotate-arch/annotate-x86.c b/tools/perf/util/annotate-arch/annotate-x86.c
> index 3a6ea7e978e0a..e38a4e7a54d55 100644
> --- a/tools/perf/util/annotate-arch/annotate-x86.c
> +++ b/tools/perf/util/annotate-arch/annotate-x86.c
> @@ -207,6 +207,29 @@ static int x86__cpuid_parse(struct arch *arch, const char *cpuid)
>  }
>  
>  #ifdef HAVE_LIBDW_SUPPORT
> +/*
> + * Get the return type of the C++ virtual function at the @offset in the
> + * vtable of @class_die.  Returns false if it's not found or the function
> + * returns void.
> + */
> +static bool vtable_get_rettype(Dwarf_Die *class_die, int offset,
> +			       Dwarf_Die *type_die)
> +{
> +	Dwarf_Die func_die;
> +	int index;
> +
> +	if (offset < 0)
> +		return false;
> +
> +	/* TODO: arch-dependent pointer size */
> +	index = offset / sizeof(void *);
> +
> +	if (die_find_virtual_func(class_die, index, &func_die) == NULL)
> +		return false;
> +
> +	return die_get_real_type(&func_die, type_die) != NULL;
> +}

[ ... ]

> @@ -615,13 +662,39 @@ static void update_insn_state_x86(struct type_state *state,

[ ... ]

>  		/* And then dereference the pointer if it has one */
>  		else if (has_reg_type(state, sreg) && state->regs[sreg].ok &&
>  			 state->regs[sreg].kind == TSR_KIND_TYPE &&
>  			 die_deref_ptr_type(&state->regs[sreg].type,
>  					    src->offset + state->regs[sreg].offset, &type_die)) {
> +			/*
> +			 * The vtable pointer of a C++ object needs the class
> +			 * to resolve virtual calls through it.
> +			 */
> +			if (!src->multi_regs && die_is_vtbl_ptr_type(&type_die) &&
> +			    die_deref_vptr_class(&state->regs[sreg].type,
> +						 src->offset + state->regs[sreg].offset,
> +						 &type_die))

[Severity: Medium]
Can malformed DWARF debug info with cyclic DW_TAG_inheritance entries trigger
unbounded recursion and overflow the stack when resolving C++ virtual calls
here?

In tools/perf/util/annotate-arch/annotate-x86.c, update_insn_state_x86() and
vtable_get_rettype() wire in the first calls to die_deref_vptr_class() and
die_find_virtual_func(), both of which reach die_get_vptr_class() in
tools/perf/util/dwarf-aux.c:

  update_insn_state_x86()
    -> die_deref_vptr_class()
      -> die_get_vptr_class()

  vtable_get_rettype()
    -> die_find_virtual_func()
      -> __die_find_primary_base_cb()
        -> die_get_vptr_class()

Even if die_deref_ptr_type() succeeds first because a class's _vptr
DW_TAG_member precedes an offset-0 DW_TAG_inheritance entry,
vtable_get_rettype() -> die_find_virtual_func() subsequently walks all
offset-0 DW_TAG_inheritance children via __die_find_primary_base_cb() and
calls die_get_vptr_class(&base_die, 0, &vptr_die).

Although die_find_virtual_func() and die_get_vptr_class() check
++chase > MAX_TYPE_CHASE in their outer loops to guard against cyclic
inheritance, the first iteration of die_get_vptr_class() invokes
__die_find_member_offset_cb():

  tools/perf/util/dwarf-aux.c:die_get_vptr_class() {
      ...
		if (++chase > MAX_TYPE_CHASE) {
			pr_debug("DWARF: base class chase limit reached at DIE 0x%lx\n",
				 (unsigned long)dwarf_dieoffset(type_die));
			return NULL;
		}

		if (die_find_child(&class_die, __die_find_member_offset_cb,
				   (void *)(long)offset, &member_die) == NULL)
			return NULL;
      ...
  }

Inside __die_find_member_offset_cb(), any DW_TAG_inheritance child with
offset >= loc recursively invokes die_find_child() with
__die_find_member_offset_cb() again without a recursion depth bound:

  tools/perf/util/dwarf-aux.c:__die_find_member_offset_cb() {
      ...
	if (tag == DW_TAG_inheritance) {
		if (offset < loc)
			return DIE_FIND_CB_SIBLING;

		if (die_get_real_type(die_mem, &base_die) == NULL)
			return DIE_FIND_CB_SIBLING;

		if (die_find_child(&base_die, __die_find_member_offset_cb,
				   (void *)(long)(offset - loc), &member_die))
			return DIE_FIND_CB_END;
      ...
  }

Does this recursion in __die_find_member_offset_cb() bypass the
MAX_TYPE_CHASE check in die_get_vptr_class() on cyclic DW_TAG_inheritance
graphs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103155650.269973-1-yzhao62@ncsu.edu?part=3

      reply	other threads:[~2026-11-03 16:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 15:56 [PATCH v4 0/3] perf annotate: Data type profiling support for C++ classes and virtual calls Yanbo Zhao
2026-11-03 15:56 ` [PATCH v4 1/3] perf dwarf-aux: Add die_is_compound_type() to handle C++ class types Yanbo Zhao
2026-11-03 16:09   ` sashiko-bot
2026-11-03 15:56 ` [PATCH v4 2/3] perf dwarf-aux: Add C++ vtable helpers Yanbo Zhao
2026-11-03 16:22   ` sashiko-bot
2026-11-03 15:56 ` [PATCH v4 3/3] perf annotate: Resolve C++ virtual function calls in x86 insn tracking Yanbo Zhao
2026-11-03 16:40   ` sashiko-bot [this message]

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=sashiko-outbox-195734@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yzhao62@ncsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox