[PATCH] D40657: [sanitizer] Introduce a vDSO aware time function, and use it in the allocator

Kostya Kortchinsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 30 12:24:19 PST 2017


cryptoad added a comment.

@krytarowski: so directly call the syscall on NetBSD or is there a possible performance gain calling the libc function as opposed to the syscall?



================
Comment at: lib/sanitizer_common/sanitizer_linux.cc:468
+extern "C" SANITIZER_WEAK_ATTRIBUTE
+int __vdso_clock_gettime(clockid_t clock, struct timespec* ts);
+bool CanUseVDSO() {
----------------
mcgrathr wrote:
> Don't rely on these libc internals.  Just look up the real `__vdso_clock_gettime` symbol in the vDSO itself.  On some machines glibc defines a `__vdso_clock_gettime` symbol also, which is a mangled pointer, not a function as declared here.  But that's purely a libc implementation detail (it's a `GLIBC_PRIVATE` symbol) and you shouldn't pay attention to that at all.  On x86, there is no such symbol in libc and so `__vdso_clock_gettime` will reach the actual vDSO function.  But since the name is sometimes overloaded, what you probably want to do is find the vDSO with `dlopen` or suchlike and then use `dlsym` to look up `__vdso_clock_gettime` directly in the vDSO.
So __vdso_clock_gettime here is not used in any capacity but very that if it exists, it's not null.
The reason being that calling clock_gettime from a preinit_array crashes on a NULL deref  (or bad demangled pointer deref).
In an ideal world I don't think that should be the case, so I am trying to work around this.

While I totally agree that it's hackish, it felt more portable than going through our own vDSO symbol resolution (with multiple architectures, multiple symbold names, etc), which it's already done at some point by the libc.
Regarding alternatives:
- dlsym uses calloc and I am not really keen on adding a special calloc case from dlsym as ASan does;
- doing our own ELF parsing could be the alternative and getting the base of the vDSO via getauxval, but the ratio of additional code & complexity versus value seems low.


https://reviews.llvm.org/D40657





More information about the llvm-commits mailing list