Page MenuHomePhabricator

[compiler-rt][AArch64] Add a workaround for Exynos 9810
Needs ReviewPublic

Authored by bc-lee on Wed, Nov 24, 4:08 AM.

Details

Summary

Big.LITTLE Heterogeneous architectures, as described by ARM [1],
require that the instruction set architecture of the big and little
cores be compatible. However, the Samsung Exynos 9810 is known to
have different ISAs in its core.
According to [2], some cores are ARMv8.2 and others are ARMv8.0.

Since LSE is for ARMv8.1 and later, it should be disabled
for this broken CPU.

[1] https://developer.arm.com/documentation/den0024/a/big-LITTLE-Technology
[2] https://github.com/golang/go/issues/28431

Diff Detail

Event Timeline

bc-lee created this revision.Wed, Nov 24, 4:08 AM
bc-lee requested review of this revision.Wed, Nov 24, 4:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptWed, Nov 24, 4:08 AM
Herald added a subscriber: Restricted Project. · View Herald Transcript
bc-lee edited projects, added Restricted Project; removed Restricted Project.Wed, Nov 24, 4:13 AM
bc-lee removed a subscriber: Restricted Project.
Herald added a project: Restricted Project. · View Herald TranscriptWed, Nov 24, 4:13 AM
bc-lee updated this revision to Diff 389729.Thu, Nov 25, 3:59 AM
bc-lee edited the summary of this revision. (Show Details)

I noticed that using __system_property_get from a constructor function probably doesn't work within the Bionic loader (linker[64]), but maybe Bionic ought to be fixed (and it shouldn't matter much in practice):

  • The Bionic dynamic loader calls the constructor functions before calling __system_properties_init. (see tmp_linker_so.call_constructors();)
  • However, a static executable calls __system_properties_init before the constructors, so static executables should be OK.
  • Maybe the dynamic loader ought to call __system_properties_init before constructors.
  • Calling __system_property_get before __system_properties_init is probably OK? It looks like SystemProperties::Find would return nullptr, and __system_property_get would return 0.
  • In any case, it wouldn't actually matter unless someone ran a new loader on an affected device+kernel.

If someone (e.g. LineageOS?) upgrades the platform to something with outline atomics, without fixing the kernel, then this bug could start to matter. I *think* Bionic can be fixed, though.

Also: is it OK to use a mix of LSE and non-LSE atomic operations to access the same memory concurrently? I would think that should be fine, but it seems worth mentioning.