http://sourceware.org/bugzilla/show_bug.cgi?id=13600
--- Comment #13 from rguenther at suse dot de 2012-01-19 13:22:03 UTC --- On Thu, 19 Jan 2012, amodra at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=13600 > > --- Comment #12 from Alan Modra <amodra at gmail dot com> 2012-01-19 12:49:02 > UTC --- > > Well, if I put that constant into a shared library _and_ I put one into > > the executable I'm still lost, no? > > No, because shared libraries must be -fpic/PIC and as you note > > > Btw, with -fPIC or -fPIE GCC puts the constants in .data.rel.ro > > instead. > > and .data.rel.ro can have relocs. > > > Which means a lost optimization (we need to go through the GOT here). > > Choose your poison. :) > > > Still, if GCC tells ld to resolve the address of a protected visibility > > foo in a shared lib without a relocation why can't it simply do so > > as surely it is techincally possible? > > It is possible, but will break function pointer comparisons if a pointer to > foo > is passed between the shared lib and executable in either direction, since the > address of foo in the shared lib and the address of the same foo in the > executable will be different. True. Just GCC did it that way since forever ... I don't have older ld to verify if only now ld rejects this behavior (there is certainly a set of programs that were not affected by this "bug" of GCC that now ld breaks). We'll fix the GCC issue on the GCC side. Richard. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
