Re: [PATCH 2/9] perf thread-stack: Report branch stack hw_idx as not available

[Adrian Hunter <adrian.hunter@intel.com>]

On 12/08/2026 19:04, Arnaldo Carvalho de Melo wrote:
> On Wed, Aug 12, 2026 at 06:48:24PM +0300, Adrian Hunter wrote:
>> On 11/08/2026 18:58, Adrian Hunter wrote:
>>> On 03/08/2026 12:06, Amir Ayupov wrote:
>>>> thread_stack__br_sample() and thread_stack__br_sample_late() fill a
>>>> caller-supplied branch_stack that is typically allocated with zalloc(),
>>>> leaving hw_idx as 0. Zero is a valid hardware index, so consumers that
>>>> honour PERF_SAMPLE_BRANCH_HW_INDEX see a reconstructed branch stack
>>>> claiming to start at LBR TOS entry 0.
>>>>
>>>> These branch stacks are reconstructed from instruction trace and have no
>>>> hardware index at all. Set hw_idx to -1ULL, which is the established way
>>>> to say "not available" and matches what intel-pt and cs-etm already put
>>>> in the branch stacks they synthesise directly.
>>>>
>>>> Signed-off-by: Amir Ayupov <aaupov@fb.com>
>>>
>>> Fixes tag?
>>>
>>> Otherwise:
>>>
>>> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
>>
>> On second thoughts, it seems that hw_idx is only used for stitching
>> LBRs which is anyway disabled by default and only enabled by --stitch-lbr.
>>
>> Setting -1ULL will prevent has_stitched_lbr() making a match, but we can
>> rely on the user to decide that for themselves via --stitch-lbr.
> 
> This is one of those options that few people use as its so specialized,
> do you think we could auto-enable it if we notice it is a good idea for
> some specific machine and request from the user? I.e. user requests
> callchains, unlimited or with a limit that is more than what we can do
> without stitching: we auto stich?

For hardware LBRs, stitching is guesswork, so the option
helps users to be informed about that:

  --stitch-lbr

  Show callgraph with stitched LBRs, which may have more complete callgraph. The 
  perf.data file must have been obtained using perf record --call-graph lbr. 
  Disabled by default. In common cases with call stack overflows, it can recreate 
  better call stacks than the default lbr call stack output. But this approach is 
  not foolproof. There can be cases where it creates incorrect call stacks from 
  incorrect matches. The known limitations include exception handing such as 
  setjmp/longjmp will have calls/returns not match.

For auxtrace, the perf thread_stack implementation can accumulate
arbitrarily large branch stacks or call stacks, so stitching
doesn't seem to make much sense in that case.

> 
> - Arnaldo
>  
>> So, in fact, it doesn't look like this change should be needed?
>>
>>>
>>>> ---
>>>>  tools/perf/util/thread-stack.c | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/tools/perf/util/thread-stack.c b/tools/perf/util/thread-stack.c
>>>> index c5ce741b07446..1a3dffa83bde2 100644
>>>> --- a/tools/perf/util/thread-stack.c
>>>> +++ b/tools/perf/util/thread-stack.c
>>>> @@ -624,6 +624,7 @@ void thread_stack__br_sample(struct thread *thread, int cpu,
>>>>  	unsigned int nr;
>>>>  
>>>>  	dst->nr = 0;
>>>> +	dst->hw_idx = -1ULL;
>>>>  
>>>>  	if (!ts)
>>>>  		return;
>>>> @@ -686,6 +687,7 @@ void thread_stack__br_sample_late(struct thread *thread, int cpu,
>>>>  	bool start = false;
>>>>  
>>>>  	dst->nr = 0;
>>>> +	dst->hw_idx = -1ULL;
>>>>  
>>>>  	if (!ts)
>>>>  		return;
>>>