Re: [DISCUSSION] Three problems behind broken "perf --call-graph dwarf" on AMD: IP and stack dump mismatch, libdw fails on lld's layout, and the unwinder fallback never runs

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 9/3/2026 7:59 PM, Mi, Dapeng wrote:
> On 9/3/2026 7:36 PM, Ravi Bangoria wrote:
>>>>> This should resolve the DWARF unwinding issue with IBS PMUs:
>>>>>
>>>>> --- a/arch/x86/events/amd/ibs.c
>>>>> +++ b/arch/x86/events/amd/ibs.c
>>>>> @@ -1523,8 +1523,11 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
>>>>>  			goto out;
>>>>>  		}
>>>>>  
>>>>> -		set_linear_ip(&regs, ibs_data.regs[1]);
>>>>> -		regs.flags |= PERF_EFLAGS_EXACT;
>>>>> +		if (event->attr.sample_type & PERF_SAMPLE_IP) {
>>>>> +			data.ip = ibs_data.regs[1];
>>>>> +			data.sample_flags |= PERF_SAMPLE_IP;
>>> We may not set PERF_SAMPLE_IP here, otherwise the kernel address leakage
>>> check in perf_instruction_pointer() could be bypassed.
>> Yes. I realized this wouldn't be straightforward, since the privilege
>> level might change between when the HW captures the sample and when the
>> NMI is delivered. So, any perf code that depends on user_mode() (e.g.
>> perf_exclude_event(), _REGS_USER, _REGS_INTR, header->misc, etc.) may
>> regress with the above change. In addition, guest entry/exit occurring
>> between sample capture and NMI delivery further complicates the problem.
>>
>>>> Right, that's what I thought.  And I believe we should do similar on
>>>> Intel and not update other registers.
>>> For Intel PEBS, the call-chain would always use the interrupt regs instead
>>> of the PEBS regs, so there would be no issues for Intel PEBS.
>>>
>>>     /*
>>>      * We must however always use iregs for the unwinder to stay sane; the
>>>      * record BP,SP,IP can point into thin air when the record is from a
>>>      * previous PMI context or an (I)RET happened between the record and
>>>      * PMI.
>>>      */
>>>     perf_sample_save_callchain(data, event, iregs);
>> This wouldn't take care of _STACK_USER, right?
> Yes, I just realized this is not fully correct for Intel PEBS after sending
> the comments.
>
> On Intel platforms, for SAMPLE_STACK_USER, the IP/SP/BP is consistent and
> they all comes from PEBS, so the DWARF unwinding has no issues. But for
> SAMPLE_CALLCHAIN, it's not consistent, the IP is overwritten by PEBS while
> the BP/SP are still gotten from PMI. So the kernel call-chain unwinding
> could not work.

The statement about SAMPLE_CALLCHAIN is not correct. Just went though the
code carefully, the kernel has already returned a IP chain to user space
for SAMPLE_CALLCHAIN requirement, which doesn't need to current IP/SP/BP
registers to reconstruct the call chain. So We only need to ensure the PMI
context registers are reported for SAMPLE_STACK_USER requirement. Thanks.


>
> Suppose we need to follow below 2 rules to ensure the correct call-chain
> unwinding and register snapshot consistency.
>
> 1. All registers including IP should come from either PEBS or PMI, must not
> be mixed. This ensures to get an consistent registers snapshot.
>
> 2. Either SAMPLE_CALLCHAIN or SAMPLE_STACK_USER is required, the PMI
> registers snapshot must be used. This proves the correct DWARF unwinding.
>
> How's your idea?
>
> Thanks.
>
>
>> Thanks,
>> Ravi