[Bug ld/13600] protected visibility creates bogus relocation

[rguenther at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=13600

--- Comment #7 from rguenther at suse dot de 2012-01-19 10:22:22 UTC ---
On Thu, 19 Jan 2012, amodra at gmail dot com wrote:

> http://sourceware.org/bugzilla/show_bug.cgi?id=13600
> 
> --- Comment #6 from Alan Modra <amodra at gmail dot com> 2012-01-19 10:00:36 
> UTC ---
> In comment #2 I was forgetting what we do in an executable.  In the main
> executable (which might be non-PIC), if we take the address of foo and the
> address of foo is written into a read-only section (.text or .rodata or
> somesuch) then we have a problem.  You've got three choices:
> a) either the address location needs a dynamic relocation which results in 
> that
> page of the executable being non-shared, or
> b) we need the hack of making the address of foo be the plt code for foo in 
> the
> executable, with all the pain in ld.so that causes, or
> c) you ensure that function addresses never appear in read-only sections.
> 
> At the moment we do (b), so I was wrong to say this was a ld bug unless it's
> true that x86_64 gcc already does (c).

Why is it not a ld bug that it doesn't do what GCC asks it to do?
That is, bind foo locally?  It sure can do that.  Whether what GCC
asks it to do is "bad" is a completely different issue, no?

For the issue you bring up you are thinking of

extern void foo (void);
const void *p = (void *)foo;

?  Regardless of if the app is PIC, PIE or not GCC generates

.globl p
        .data
        .align 8
        .type   p, @object
        .size   p, 8
p:
        .quad   foo

thus, it doesn't put p into .rodata (it needs a relocation after all).

So, how would you put those function address into a readonly section?

-- 
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.