On Thu, Mar 27, 2014 at 02:12:54PM +0400, izbyshev wrote: > On 2014-03-24 23:53, Trevor Saunders wrote: > >On Mon, Mar 24, 2014 at 10:00:33AM -0400, Benjamin Smedberg wrote: > >>We would not like to use -fvisibility=hidden everywhere! > >>-fvisibility=hidden > >>is strictly worse than using the pragmas because it only affects symbol > >>generation and doesn't affect symbol resolution. This means that we > >>still > >>have to use dynamic relocations against internal symbols when we should > >>be > >>using hidden relocations (on ELF platforms). It doesn't matter nearly as > >>much or at all on Mach-O/PE which use startup relocations instead of a > >>GOT/PLT. > >The documentation doesn't make it clear that's the case, and it seems > >like a very odd way of doing things. In addition if it is the case then > >I'm amazed linux builds I've done with -fvisibility=hidden only had 7k > >more relocations than ones using the wrappers for all of libxul. > > > > Well, actually the documentation at http://gcc.gnu.org/wiki/Visibility > states: > > #pragma GCC visibility is stronger than -fvisibility; it affects extern > declarations as well. -fvisibility only affects definitions, so that > existing code can be recompiled with minimal changes.
that seems kind of crazy and unfortunate. > Now the declaration of 'x' is hidden, and the pc-relative access without GOT > is generated. There is no relocation for 'x' in .so. > IIUC the situation above is what Benjamin means. However, external function > calls are another story -- again IIUC, the code on the caller's side doesn't > depend on visibility at all before linking since even when PLT is used, the > dereferencing of an address from GOT is done inside the PLT stub, not at the > callsite. Given that internal functions are not called via PLT, a .so should > never contain relocations for them. > > So, in theory, the choice '-fvisibility=hidden' vs system wrappers should > affect only relocations for data, and it would explain why the difference is > only ~7K for firefox. I've tried to test the hypothesis, and here is the > results of my firefox builds (elfhack disabled, -O3): Seems reasonable. > There is always a small difference in .rela.plt, which seems like a > contradiction. I've investigated a group of opus_* functions from libopus > that have relocations for them in -fvisibility=hidden builds. It turned out > that libopus uses OPUS_EXPORT which sets visibility to default but only if > OPUS_BUILD macro is set. Since libopus is built with -DOPUS_BUILD, opus_* > functions always have default visibility in its object files. However, a > user of libopus (somewhere in webrtc) is not built with -DOPUS_BUILD, and > OPUS_EXPORT is not set on declarations in this case. Therefore, if #pragma > is set, it sets the visibility of declarations to 'hidden', and when > libxul.so is linked, the hidden symbols from webrtc are merged with the > default from libopus and become hidden, so relocations are not used. With > -fvisibility=hidden the symbols have default visibility everywhere, and thus > in libxul.so, so the relocations must be used. Well, presumably webrtc doesn't define any symbols it just refers to them and then maybe the linker decides if some people in the shared object expect the symbol in the same shared object then any other references can too??? Anyway it seems like the opus stuff is kind of buggy, I doubt we want those symbols to be exported from libxul. > All in all, it seems that system wrappers are superior (but not > dramatically) unless all internal data used across units is explicitly > marked with 'hidden' attribute and issues like with libopus are resolved (by > either changing such libs so they don't export symbols when they are built > statically or explicitly marking function declarations as hidden at use > sites). or we get gcc / clang to make -fvisibility=hidden do what we want / add some new option that does. Trev > > -- > Alexey Izbyshev > > > > > > > > > > > > > > _______________________________________________ > dev-builds mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-builds _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
