Instead of hand-crafting an offset into the structure returned by
dlopen(3) to get at the link map, use the documented API. This is
described in dlinfo(3): by calling it with RTLD_DI_LINKMAP, the
dynamic linker ensures the right address is returned.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
95 | should be void *__sanitizer_get_link_map_by_dlopen_handle(void* handle) { clang-format it |
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
95 | Should be void *__sanitizer_get_link_map_by_dlopen_handle(void *handle) { |
It will be nice to include in the description what systems were not supported by hard coding 560, if such information can be obtained relatively easily.
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
95 | Eh, what do you mean? It's already that form? |
systems were not supported by hard coding 560
In the NetBSD case this offset changes few times a year.
I don't quite understand this question; hard coding is definitely a hack and we should prefer the supported method for finding the information, if the system provides it.
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.h | ||
---|---|---|
28–29 | I don't think the comment is applicable now |
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.h | ||
---|---|---|
28–29 | Well, it is still informative in the sense that it tells you the handle parameter (which is apparently the return value from dlopen) does not directly point to the desired link map information Would you rather delete the comment, or replace it with something else? If the latter, what? :) |
Btw, note that according to the Linux dlinfo() manpage, it also has RTLD_DI_LINKMAP as a documented way to get at the link map. Maybe we should generalize this in a follow-up review?
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
96 | Actually please add internal_dlinfo() alongside internal_pid() and others. It's sufficient to redirect it for all supported OSs (Linux, FreeBSD, Solaris, NetBSD) to dlinfo() for now and stub /* unimplemented */ for others. On NetBSD we need to use it indirectly and handle it later. |
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
96 | Hm, I don't see any internal_pid() anywhere, but there are quite a lot of internal_ functions in compiler-rt/lib/sanitizer_common/sanitizer_libc.cpp. Is that the right location? It seems that these are all more like hand-rolled versions of known libc functions, not some sort of 'forwarders'. |
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.cpp | ||
---|---|---|
96 | Right, I was thinking about internal_getpid(). We wrap other functions too like sysctl(). |
- Rebase onto reformatted files.
- Add internal_dlinfo() for FreeBSD and NetBSD, with stubs for other platforms.
- Add GET_LINK_MAP_BY_DLOPEN_HANDLE() macro for NetBSD.
compiler-rt/lib/sanitizer_common/sanitizer_netbsd.cpp | ||
---|---|---|
269 | So as we implemented it for NetBSD here. Please put it in the expected final form. DEFINE__REAL(int, dlinfo, void *a, int b, void *c); return _REAL(dlinfo, handle, request, p); |
compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_freebsd.h | ||
---|---|---|
28–29 | I would delete it - the macro name is pretty explicit about obtaining the link map from the dlopen handle :-) |
This breaks in our downstream runtimes builds for armv7-none-linux-androideabi16. FYI
Can you point me to some build logs? (I didn't receive any failure mails from bots yet.)
Our bots are not public, but I have a patch that I can post shortly. If you check the android NDK you'll see that it does not implement dlinfo.
I found this lab builder, which gave a similar error: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android
Committed a slightly different version in rG52f2df1ecdd79cc550b694ab280f3b0396d7cf9a, thanks for the heads up!
So as we implemented it for NetBSD here. Please put it in the expected final form.