executable's TLS segment is underaligned

[JayXon]

01-30 14:34:48.711 17494 17494 D shadowsocks: plugin "/data/app/com.github.shadowsocks.plugin.v2ray-n4J1iJa1RLMutq1cBcy
aTw==/lib/arm64/libv2ray.so -V" enabled
01-30 14:34:48.748 17536 17536 W libv2ray.so: type=1400 audit(0.0:12977): avc: denied { getattr } for path="/postinstal
l" dev="dm-0" ino=29 scontext=u:r:untrusted_app_27:s0:c200,c256,c512,c768 tcontext=u:object_r:postinstall_mnt_dir:s0 tc
lass=dir permissive=0 app=com.github.shadowsocks
01-30 14:34:48.752 17536 17536 F libc    : error: "/data/app/com.github.shadowsocks.plugin.v2ray-n4J1iJa1RLMutq1cBcyaTw
==/lib/arm64/libv2ray.so": executable's TLS segment is underaligned: alignment is 8, needs to be at least 64 for ARM64
Bionic
01-30 14:34:48.752 17536 17536 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 17536 (libv2ray.so), pid
 17536 (libv2ray.so)

[JayXon]

Seems to be a golang issue: golang/go#29674

[rprichard]

When I last looked at this, Go was placing a TLS segment (and a runtime.tlsg TLS symbol) into Go binaries, but it didn't actually use either of them. The symbol Go actually cares about is a non-TLS runtime.tls_g symbol with an underscore. If Go omitted the TLS segment (or overaligned it, I suppose), its executables would work again on the latest Android platform.

(That said, Go is still making problematic assumptions about how Bionic lays out TLS memory that might be invalidated in the future.)

[eliasnaur]

@rprichard will you remove or overlalign the unused TLS segment as part of your work on golang/go#29674?

[kvaster]

My comment is not about this project, but about problem in general.
I have this problem on Android Q Beta with syncthing project.
But I can say that @rprichard is right. I've monkey-patched resulting .so binaries. I've modified TLS segment alignment and now I'm having working syncthing. The bad thing - I had to really hex-patch binary.

Catfriend1/syncthing-android#370 (comment)