Hi Richard, > Can you go into more detail about: > > Use :option:`-mdirect-extern-access` either in shared libraries or in > executables, but not in both. Protected symbols used both in a shared > library and executable may cause linker errors or fail to work correctly > > If this is LLVM's default for PIC (and by assumption shared libraries), > is it then invalid to use -mdirect-extern-access for any PIEs that > are linked against those shared libraries and use protected symbols > from those libraries? How would a user know that one of the shared > libraries they're linking against was built in this way?
Yes, the usage model is that you'd either use it for static PIE or only on data that is not shared. If you get it wrong them you'll get the copy relocation error. In the future we need to decide what the ABI is and ensure GCC and LLVM are compatible. An import feature to mark symbols that may be overridden by a shared library would be useful too. > It looks like the main difference between this implementation and > the x86 one is that x86 allows direct accesses to common symbols. > What's the reason for not doing that for AArch64? Does it not work, > is it a false optimisation (i.e. pessimisation), or did it not seem > important now that -fno-common is the default? I don't see any difference in the way common symbols are accessed on x86, so it's not clear which cases common_local_p param actually affects (eg. with -fPIC there is always a GOT indirection for common symbols). Cheers, Wilco
