[FMV][AArch64] Fix UPASS when "SSBS not fully self-synchronizing".#167
Conversation
When running try_ssbs2() on hardware which is affected by the "SSBS not fully self-synchronizing" errata, the linux kernel mutes the detection of ssbs2 via hardware caps. As a result the default version ends up running the ssbs2 code which was expected to trap originally. To work around this UPASS I have created a whitelist of functions which are expected to return a different status result. This fixes llvm/llvm-project#109304.
* replaced the exemption list with an additional macro parameter * added comments explaining the UPASS for ssbs2 * added surrounding parentheses for the exit condition
Don't stringify IS_EXEMPT macro parameter.
|
@labrinea I'm seeing
Of course changing the parameter value from |
|
@pawosm-arm without looking at any logs I can only guess what's going on. We have a builder in place with similar hardware to yours https://lab.llvm.org/buildbot/#/builders/198 which makes me think the problem may relate to your operating system or the command line used. This issue may relate to yours llvm/llvm-project#123383. |
There are no logs. I don't need to run entire suite for this to reproduce it: |
|
What happens if you specify -mcpu=neoverse-v2 (or v1 depending on which machine you're running this on)? Any better? |
Tried this on neoverse-v2. Doesn't seem to be any different: |
|
Happens also at |
|
...and at |
|
Is there anything that can be done to this issue? Our RHEL-8 CI is red for more than a month now... |
When running try_ssbs2() on hardware which is affected by the "SSBS not fully self-synchronizing" errata, the linux kernel mutes the detection of ssbs2 via hardware caps. As a result the default version ends up running the ssbs2 code which was expected to trap originally.
To work around this UPASS I am passing an additional macro parameter to indicate whether the default version is exempt from diagnostics.
This fixes llvm/llvm-project#109304.