On Mon, Aug 29, 2011 at 06:48:49PM +0200, Michel Dänzer wrote: > > Fast forward four months... > > On Sam, 2011-04-30 at 20:04 +0200, Mike Hommey wrote: > > On Sat, Apr 30, 2011 at 12:00:41PM +0200, Mike Hommey wrote: > > > On Thu, Apr 28, 2011 at 02:17:15PM +0200, Gabriel Paubert wrote: > > > > On Thu, Apr 28, 2011 at 12:10:54PM +0200, Mike Hommey wrote: > > > > > On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote: > > > > > > Let me write it again: > > > > > > - The R_PPC_REL24 relocations are all over libxul.so on objects > > > > > > that are > > > > > > built -fPIC. > > > > > > - libcrmf.a is also linked into libxul.so, and it also contains > > > > > > R_PPC_REL24 relocations, but all the objects it contains are built > > > > > > -fPIC. > > > > > > > > > > And this is a -Os bug, apparently. Building with -O2 doesn't seem to > > > > > yield these relocations. > > > > > > > > That's because the out-of-line prologue/epilogue register save and > > > > restore functions are only used at -Os (they save size). > > > > > > > > Now I believe, but don't quote me on that, that the linker > > > > should insert a copy of these functions in every shared library > > > > since these functions have non standard linkage and probably > > > > would not survive crossing shared library boundaries. > > > > > > > > I can see a bug if the shared library text size is above > > > > 32M or so (needs several copies of these functions), but > > > > I don't think the libraries are that big. > > > > > > The linker actually normally does that, because it compiles with -lgcc, > > > which will link libgcc.a, which contains these functions. > > > > > > However, for some reason, in libxul.so case, gcc uses -shared-libgcc, > > > which I fail to see where it collects it from (thanks KiBi for the > > > verbose build, see below). > > > > > > OTOH, I still can't reproduce with a simple test case. The linker still > > > seems to do the right thing. Even if I use the same build flags. > > > I really don't know what makes the libxul.so case so special. Its size? > > > > So, the problem is its compile line, containing > > -lstartup-notification-1, and has nothing to do with -shared-libgcc. > > > > It looks like startup-notification was built with a broken toolchain in > > 2009 (will ask for a binNMU), and exported the _rest* symbols that > > libgcc.a also contains. As -lstartup-notification-1 appears before -lgcc > > on the link line, ld wrongly picks the versions in > > startup-notification-1. > > > > So it looks to me like there were and are several problems: > > - The original problem that made startup-notification export these > > symbols, that is gone. > > - gcc, that doesn't mark _rest* symbols as hidden in object files (they > > are in libgcc.a) > > > > I guess fixing the latter would either force ld to use the libgcc.a > > symbols or fail to link with the startup-notification symbols. > > /usr/lib/xulrunner-6.0/libxul.so still has lots of these R_PPC_REL24 > relocations, and today this prevented iceweasel from starting at all for > me, as one of them ended up unresolvable. > > AFAICT the libstartup-notification0 problem should be fixed now. Is this > just a gcc -Os / binutils bug that should be worked around at least for > now by building with -O2? I'm successfully running iceweasel with > libxul.so rebuilt with -O2, it's 100% R_PPC_REL24 free. > > (I wonder if it's worth trying to use -Os at all, given all the trouble > it's caused; AFAIK it's also known to result in generally rather bad > code generation...)
Interestingly, according to bug #639851, 6.0-2 didn't have the problem. Which suggests something else broke. Mike -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110831043509.gc3...@glandium.org
