Branch: refs/heads/main
Revision: 413d3809cfafe69ef497c077adea003e30b38ea9
Author: dlongnecke-cray
Link: dlopen: Fetch the 'dlopen' handle for the current locale before doing 'dlsym' by dlongnecke-cray · Pull Request #27207 · chapel-lang/chapel · GitHub
Log Message:
dlopen: Fetch the 'dlopen' handle for the current locale before doing 'dlsym' (#27207)
This PR fixes a silly bug that was breaking the
LoadForeignLibrary.chpl test on linux64. It turns out that we were
incorrectly using the dlopen handle for Locales[0] on any other
locale. This PR makes sure to grab the handle for the currently
executing locale out of the buffer stored on Locales[0].
The reason this bug was not observed on OSX is because, at least on my
machine, when a shared object is dynamically loaded, it appears to be
seated in the same virtual address range regardless of the process. I
observed the following debugging output on OSX:
path: './TestCLibraryToLoad.so'
system-pointers: 0x4604bd80 0x4604bd80 0x4604bd80 0x4604bd80
opened symbols:
This isn't a bug: each different locale's process loaded up
./TestCLibraryToLoad.so at the same exact virtual address. Note that
there's no launcher and GASNET_SPAWNFN=L, so we're oversubscribing.
On linux64 each locale presented a different address for the loaded in
shared library.
I'm not sure if this is:
- Some failure for OSX to adhere to ASLR
- The OSX dynamic loader being able to get away with mapping to the same
virtual address range - Or the shared library being pinned for some reason (not fully
relocatable?! I compiled with-fPIC) - Maybe ASLR for libraries is just weaker on OSX?
But it's interesting nonetheless.
TESTING
-
ALLonlinux64
Reviewed by @jabraham17. Thanks!
Diff:
M modules/internal/ChapelDynamicLoading.chpl
D test/dynamic-loading/LoadForeignLibrary.skipif
https://github.com/chapel-lang/chapel/pull/27207.diff