bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/13600] protected visibility creates bogus relocation


From: rguenther at suse dot de
Subject: [Bug ld/13600] protected visibility creates bogus relocation
Date: Thu, 19 Jan 2012 13:22:03 +0000

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]