Open Quuxplusone opened 6 years ago
Bugzilla Link | PR37545 |
Status | NEW |
Importance | P normal |
Reported by | Richard Smith (richard-llvm@metafoo.co.uk) |
Reported on | 2018-05-21 13:05:51 -0700 |
Last modified on | 2018-06-11 17:56:03 -0700 |
Version | unspecified |
Hardware | PC Linux |
CC | kcc@google.com, llvm-bugs@lists.llvm.org, rnk@google.com, vitalybuka@google.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
Not sure what to do here.
We can't instrument weak definitions...
We can just avoid instrumenting typeinfo globals as a workaround...
If the global registration data referred to the copy of the symbol from that DSO rather than the one selected by the dynamic linker, I think that would resolve this problem. (I don't know for sure, but I think it may be possible to get that effect by changing the global to an internal symbol with a new name, and adding an external-linkage alias to it with the original name, then using the non-alias name only for the ASan registration data.)
The alias trick would work, I guess. Instrumented IR transform would look like:
@foo = global i32 42
->
@foo = global alias i32* (getelementptr {i32, [60 x i8]}* @__asan_rz_foo, i32
0, 0)
@__asan_rz_foo = internal global {i32, [60 x i8]} { i32 42, [60 x i8]
zeroinitializer }
@__asan_global_foo = ; ... same, using @__asan_rz_foo
Or, we could try to leverage dso_local information to avoid instrumenting
interposable globals. If the user sets -fPIE or doesn't explicitly set -fPIC,
we can assume that we'll be linked into an executable, and if so, everything
with a definition is dso_local, and everything should be instrumented.