https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #22 from Ulrich Weigand <uweigand at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #21) > Could libsanitizer call __tls_get_offset instead, after setting %r12 or > whatever else is needed for it to make work and then perhaps adjust the > result if needed? > E.g. on s390x __tls_get_offset is internally: > __tls_get_offset:\n\ > la %r2,0(%r2,%r12)\n\ > jg __tls_get_addr\n\ > and in the interceptor: > #ifdef __s390x__ > "la %r2, 0(%r2,%r12)\n" > "jg __interceptor___tls_get_addr_internal_protected\n" > #else > at which point the original %r2 and %r12 is lost and it is hard to call the > original __tls_get_offset, it might be better to pass the original %r2 and > %r12 values to some C function and from that compute the r2 + r12 the code > perhaps needs for its own thing, but then we could (again in assembly) call > the original __tls_get_offset again if needed. Yes, it would appear to be safer to call __tls_get_offset instead. You probably do not even need the original %r12, but simply subtract %r12 (whatever it currently is) from %r2 before calling the original __tls_get_offset. The value of %r12 is not used for anything except adding it to %r2. > That said, if asan wants to intercept also what dlsym will internally call, > then that will not really work. But does libasan on other targets rely on > dlsym calling __tls_get_addr internally in those cases? That would be yet > another reliance on glibc internals. As I understand it, they do make that assumption; libsanitizer must get involved at the point any new TLS data section is allocated. Since this allocation may happen as a result of a dlsym call, those cases have to be intercepted as well.
