[Bug target/19520] protected function pointer doesn't work right

[Bug target/19520] protected function pointer doesn't work right

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #23 from Thiago Macieira <thiago at kde dot org> 2012-01-16 14:56:50 UTC ---
I've changed my opinion on this matter. I think GCC is generating the proper
code (most efficient). It's ld that should accept this decision.

[Bug target/19520] protected function pointer doesn't work right

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-17 20:00:27 UTC ---
*** Bug 51880 has been marked as a duplicate of this bug. ***

[Bug target/19520] protected function pointer doesn't work right

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #25 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-18 09:21:14 UTC ---
LD bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13600

The GCC side is a QOI thing and maybe a conformance thing.  ICC generates
for

__attribute__((visibility("protected")))
void * foo (void) { return (void *)foo; }

        .protected foo
        .globl foo
foo:
..B1.1:                         # Preds ..B1.0
..___tag_value_foo.1:                                           #1.60
        movq      foo@GOTPCREL(%rip), %rax                      #1.77

thus does not resolve the function address to the local symbol, which GCC
does and which confuses LD (thus the linker bug):

        .globl  foo
        .protected      foo
        .type   foo, @function
foo:
.LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        leaq    foo(%rip), %rax

I think ICC this way avoids the function pointer comparison issues with
symbols with protected visibility (can someone double-check?  HJs testcase
doesn't compile for me).

[Bug target/19520] protected function pointer doesn't work right

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #26 from Thiago Macieira <thiago at kde dot org> 2012-01-18 13:28:05 UTC ---
ld *can* link, it just chooses not to.

$ cat > foo.c
__attribute__((visibility("protected")))
void * foo (void) { return (void *)foo; }

$ gcc -fPIC -shared foo.c           
/usr/bin/ld: /tmp/cclrufLV.o: relocation R_X86_64_PC32 against protected symbol
`foo' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

$ gcc -Wl,-Bsymbolic-functions -fPIC -shared foo.c && echo success
success
$ cat > empty.dynlist                                                     
{ "__this_symbol_isnt_present__"; };
$ gcc -Wl,--dynamic-list,empty.dynlist -fPIC -shared foo.c && echo success
success

I also cannot confirm that icc does anything different:
$ icc -fPIC -shared foo.c
ld: /tmp/iccf15gTK.o: relocation R_X86_64_PC32 against protected symbol `foo'
can not be used when making a shared object
ld: final link failed: Bad value
$ icc -O3 -S -o /dev/stdout -fPIC -shared foo.c | grep -A4 foo:
foo:
..B1.1:                         # Preds ..B1.0
..___tag_value_foo.1:                                           #2.19
        lea       foo(%rip), %rax                               #2.36
        ret                                                     #2.36

What's more, if you actually do compile the following program into a shared
library, it succeeds:
$ cat > foo.S
        .text
        .globl  foo
        .protected      foo
        .type   foo, @function
foo:
        movq      foo@GOTPCREL(%rip), %rax
        ret
$ gcc -shared foo.S && echo success
success

But the resulting shared object has the following (extracted from eu-readelf):
Relocation section [ 5] '.rela.dyn' for section [ 0] '' at offset 0x230
contains 1 entry:
  Offset              Type            Value               Addend Name
  0x0000000000200330  X86_64_GLOB_DAT 0x0000000000000248      +0 foo

    2: 0000000000000248      0 FUNC    GLOBAL PROTECTED      6 foo

Now we introduce a third component to this discussion: the dynamic linker. What
will it do?

This has become a decision, not a bug: what should the compiler do when taking
the address of a function when said function is under protected visibility.
Both solutions are technically correct and would load the same function address
under the correct circumstances. 

The compiler is also taking on the "protected" visibility to the letter (at
least, according to its own definition of so):

    "protected"
          Protected visibility is like default visibility except that it
          indicates that references within the defining module will
          bind to the definition in that module.  That is, the declared
          entity cannot be overridden by another module.

Since the symbol was marked as "protected" in the symbol table, it's expected
that the linker and dynamic linker will bind it locally. That being the case,
the compiler can optimise for that fact. It can calculate what value would be
placed in the GOT entry and load that instead. That's the LEA instruction.

The linker, however, mandates that the address to symbol should not be loaded
directly, but only through the GOT. This is necessary because the psABI
requires that the function address resolve to the PLT entry found in the
position-dependent executable. If the executable takes the address of this
global (but protected) symbol, it will hardcode the address to its own address
space, forcing other ELF modules to follow suit.

Finally, what does the dynamic linker do when an "entity (that) cannot be
overridden by another module" is overridden by another module? The glibc 2.14
loader will resolve the GOT entry's relocation to the executable's PLT stub,
even if the symbol in question has protected visibility. Other loaders might
work differently.

As it stands, the psABI requires that the address to a protected function be
loaded through the GOT, even though the compiler thinks it knows what the
address will be.

However, I really wish the compiler *not* to change its behaviour for PIC code,
but instead change its behaviour for ELF position-dependent executables. I am
asking for a change in the psABI and requesting that the loading of function
addresses for "default" visibility symbols (not protected!) should be done via
the GOT. In other words, I'm asking that we optimise for shared libraries, not
for executables.

Versions:
GCC: 4.6.0
ld: 2.21.51.0.6-6.fc15 20110118
ICC: 12.1.0 20111011

[Bug target/19520] protected function pointer doesn't work right

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #27 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-18 15:17:19 UTC ---
(In reply to comment #26)

> The linker, however, mandates that the address to symbol should not be loaded
> directly, but only through the GOT. This is necessary because the psABI
> requires that the function address resolve to the PLT entry found in the
> position-dependent executable.

Why on earth does it do that?  If we have to go through the GOT it can
as well contain the functions address and not that of the PLT entry?

[Bug target/19520] protected function pointer doesn't work right

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #28 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-19 13:36:28 UTC ---
Final conclusion:  We need to resolve to the executables PLT consistently,
even from inside the shared object where the function binds locally.  This
is because of references to the function from the executables .rodata section
which we can't relocate (and thus have to point to the executables PLT entry).

Thus, this is a GCC target bug.

__attribute__((visibility("protected"))) void * foo () { return foo; }

needs to return the address of foo via a load from the GOT.  HJs patch
isn't correct as this is really a target ABI choice (another ABI may
choose to resolve all references to the functions start address with
the cost of having to put the constants into a .rel.rodata section).

[Bug target/19520] protected function pointer doesn't work right

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #29 from H.J. Lu <hjl.tools at gmail dot com> 2012-01-19 18:29:39 UTC ---
(In reply to comment #28)
> Final conclusion:  We need to resolve to the executables PLT consistently,
> even from inside the shared object where the function binds locally.  This
> is because of references to the function from the executables .rodata section
> which we can't relocate (and thus have to point to the executables PLT entry).
> 
> Thus, this is a GCC target bug.
> 
> __attribute__((visibility("protected"))) void * foo () { return foo; }
> 
> needs to return the address of foo via a load from the GOT.  HJs patch
> isn't correct as this is really a target ABI choice (another ABI may
> choose to resolve all references to the functions start address with

It only applies when we take an address of a protected function.
Branch to a protected function doesn't need to go through PLT.

[Bug target/19520] protected function pointer doesn't work right

[thiago at kde dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

--- Comment #30 from Thiago Macieira <thiago at kde dot org> 2012-01-19 18:52:57 UTC ---
This does solve the problem.

It's just unfortunate that it does so by creating more work for the library
even if no executable ever takes the address of this protected function.

It would have been preferable to somehow tell the compiler when compiling an
executable that this function it's taking the address of is protected
elsewhere, so it should use the GOT too.

[Bug target/19520] protected function pointer doesn't work right

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #31 from Rich Felker <bugdal at aerifal dot cx> 2012-04-29 04:39:03 UTC ---
I think part of the difficulty of this issue is that the behavior of protected
is not well-specified. Is it intended to prevent the definition from
interposition? Or is it promising the compiler/toolchain that you won't
override the definition (and acquiescing that the behavior will be undefined if
you break this promise)?

If protected's intent is the former, then it's absolutely wrong to resolve the
function's address to the main executable's PLT entry for a different function
by the same name. To avoid this, the GOT entry for the function in the shared
library must point to the PLT entry in the main program if and only if the main
program's symbol got resolved to the library's version of the function;
otherwise, it must point to the library's version. I don't see an easy way to
arrange this without special help from the dynamic linker, and personally, I
think it's a slippery slope to try to make promises that are this difficult to
keep.

As such I'd prefer that protected's behavior be the latter: an optimization
hint to the compiler in the form of a promise not to override the definition.

In any case, I'm experiencing this bug in the form of not being able to take
the address of any external functions when using -fvisibility=protected, and
it's making it impossible to use -fvisibility=protected. I get bogus linker
errors about not being able to use a protected function for R_386_GOTOFF
relocations. So I want to see this solved in one way or another, preferably in
the way that results in maximal performance and minimal bloat while ensuring
correct behavior as long as the functions are not overridden...

[Bug target/19520] protected function pointer and copy relocation don't work right

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |55012
            Summary|protected function pointer  |protected function pointer
                   |doesn't work right          |and copy relocation don't
                   |                            |work right

--- Comment #32 from H.J. Lu <hjl.tools at gmail dot com> 2012-10-21 21:34:50 UTC ---
Protected data symbol with copy relocation doesn't
work either.