On Fri, 26 Jun 2026 22:09:52 GMT, Chris Plummer <[email protected]> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Use print_error()
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 553:
> 
>> 551:     _pac_mask = (uintptr_t)pauth_strip_pointer((address)~(UINT64_C(1) 
>> << 55));
>> 552:   }
>> 553: 
> 
> Did this code have to be moved?
> 
> It looks like the change here is making sure _pac_mask gets set even if the 
> setting of UseBranchProtection indicates that PAC will not be used. Is this 
> change needed because runtime flags are in conflict with what is in the dwarf 
> file. In other words, dwarf says PAC is supported, but hotspot has decided 
> not to enable it? However, this means you are masking addresses that are not 
> PAC signed. Are. you sure this is always ok? What if you mask off bits of the 
> actual unsigned address. It's not clear to my why SA would need _pac_mask set 
> if PAC was disabled at runtime.
> 
> BTW, where is supports_paca() defined. I'm unable to find it in the source or 
> with a web search.

I need `_pac_mask` to strip PAC, so I moved to set it even if branch protection 
is disabled.
We have to strip PAC for native frames (e.g. glibc) even if HotSpot disables 
branch protection. If PAC is enabled in the Kernel, all of native frames would 
be handled PAC if PAC instructions are issued (then it should be also recorded 
in DWARF instructions). To avoid unnecessary stripping, this PR checks PAC in 
auxiliary vector from `getauxv()`.

Now, `_pac_mask` does not seem to be used in HotSpot (excluding vmstructs), so 
I believe it does not produce side-effect (actually all of GHA workflows 
succeeded).

> where is supports_paca() defined. I'm unable to find it in the source or with 
> a web search.

It is defined in hotspot/cpu/aarch64/vm_version_aarch64.hpp via 
`CPU_FEATURE_FLAGS` macro. The flag would be set at 
`VM_Version::get_os_cpu_info()` in vm_version_linux_aarch64.cpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/31669#discussion_r3485071359

Reply via email to