Wilco Dijkstra <wilco.dijks...@arm.com> writes: > 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.
Thanks. I think I'm still missing something though. If, for the non-executable case, people should only use the feature on data that is not shared, why do we need to relax the binds-local condition for protected symbols on -fPIC? Oughtn't the symbol to be hidden rather than protected if the data isn't shared? I can understand the reasoning for the PIE changes but I'm still struggling with the PIC-but-not-PIE bits. > 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). Hmm, OK. Could it be for one of the other languages? But yeah, if we don't have a testcase for it, I agree it's better to leave things as they are. Thanks, Richard
