Android Go x86,runtime: android x86 support

最新推荐文章于 2024-01-14 12:17:44 发布

转载最新推荐文章于 2024-01-14 12:17:44 发布 · 126 阅读

文章标签：

#Android Go x86

博客讨论了Go语言在Android/386平台上遇到的TLS（线程局部存储）处理难题，由于Android链接器缺乏相应支持。目前的解决方案是模仿Darwin/386的处理方式，但这种方法存在不优雅和脆弱性。作者考虑了通过IEMode支持的可行性，但不清楚实现所需工作量。邮件线程中提及可能通过IEMode实现更清洁的解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

One obvious missing feature is the TLS handling - linux/386 assumes availability of TLS store to hold g across cgo calls, and the linker's ability to handle TLS relocation for LE mode. But android linker lacks such support.

Android/arm overcomes it by emulating runtime.tlsg as a regular variable. The same trick doesn't seem to work for 386 where the offset is encoded in the instruction when using LE model.

Instead, @crawshaw and I think the approach darwin/386 is taking (runtime/cgo/gcc_darwin_386.c) may work for android/386 as well - basically we allocate a thread-local storage with a specific key and use a hard-coded offset (cmd/link/internal/ld/sym.go line 145). This is ugly and fragile, but seems promising. Should we take this path?

In this mail thread https://groups.google.com/forum/#!topic/golang-nuts/cZPdxDmnuUM @mwhudson mentioned it may be feasible through IE model support and I guess it may be cleaner. However, not being familiar with the concept yet, I cannot estimate how much work is necessary to implement IE model support (pointer to the cl that implements IE mode for amd64 would be appreciated) and not yet clear about where to hook into the tls offset info when the linker is not doing most of the magic for me.