Re: [RFC Patch] perf regs: Remove __weak attribute from perf-regs functions

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

On 1/27/2026 1:17 AM, Ian Rogers wrote:
> On Sun, Jan 25, 2026 at 9:20 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>
>> On 1/24/2026 8:39 AM, Ian Rogers wrote:
>>> On Fri, Jan 23, 2026 at 1:13 AM Dapeng Mi <dapeng1.mi@linux.intel.com> wrote:
> [snip]
>>>> diff --git a/tools/arch/arm64/include/uapi/asm/perf_regs.h b/tools/arch/arm64/include/uapi/asm/perf_regs.h
>>>> index 86e556429e0e..43e8e08f52ed 100644
>>>> --- a/tools/arch/arm64/include/uapi/asm/perf_regs.h
>>>> +++ b/tools/arch/arm64/include/uapi/asm/perf_regs.h
>>>> @@ -43,6 +43,6 @@ enum perf_event_arm_regs {
>>>>         PERF_REG_ARM64_EXTENDED_MAX
>>>>  };
>>>>
>>>> -#define PERF_REG_EXTENDED_MASK (1ULL << PERF_REG_ARM64_VG)
>>>> +#define PERF_ARM64_REG_EXTENDED_MASK   (1ULL << PERF_REG_ARM64_VG)
>>> I think avoiding the conflicts by adding the architecture name is correct.
>> Yes, but the side effect is that there would be mismatch with the
>> corresponding kernel header file. Not sure if someone dislike it ...
> It should be possible to update the kernel headers too rather than
> have them out-of-sync with the perf ones. Someone might object but it
> doesn't seem unreasonable to make the changes to me :-)

Ok, let me do this and look at if someone doesn't like it. Thanks.


>
>>>> Additionally, there could be architecture-specific instructions called,
>>>> such as the "mfspr" instruction on PowerPC, which causes build errors on
>>>> other platforms like x86.
>>> Right, the mfspr is used to add additional registers into the mask and
>>> if we're not on a powerpc and can't run it we should assume something
>>> conservative which your change will achieve. Fwiw, I tried to see if
>>> similar information was available from say the ELF header, but I
>>> couldn't see it.
>>>
>>> With your SIMD changes and common functions you can refactor the
>>> function signature to take the e_machine and also the perf ABI enum
>>> value, then the mapping of either an XMM register string or SSP should
>>> be possible by varying the ABI enum value. You'll also know to fix up
>>> all the callers on the reading perf.data side to pass the enum value
>>> as the code won't compile with the missing parameter.
>> Yes, if we decide to use this way, the SIMD/eGPRs support would follow same
>> way.
> Great, thanks.
>
> [snip]
>
>>> I think it would be nice for the SDT clean up to be a distinct patch
>>> from the arch__user_reg_mask/arch__intr_reg_mask clean up. If there
>>> are regressions it will be easier to bisect.
>> Sure. Would split them in V2.
> Thanks!
> Ian