On Thu, Nov 17, 2022 at 5:30 PM Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
I think I'm with Richard S on hidden vs protected on first reading. I can see why this works out of the box and can even be default for static-pie. Any reason why this is not on by default - it's early enough in the stage3 cycle and we can always flip the defaults if there are more problems found. You probably need a rebase for the documentation bits,. regards Ramana Ramana
