bug-binutils
[Top][All Lists]
Advanced

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

[Bug gold/15574] New: Gold is overly pedantic for dynamic references to


From: law at redhat dot com
Subject: [Bug gold/15574] New: Gold is overly pedantic for dynamic references to symbols with hidden visibility
Date: Tue, 04 Jun 2013 20:52:20 +0000

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

            Bug ID: 15574
           Summary: Gold is overly pedantic for dynamic references to
                    symbols with hidden visibility
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gold
          Assignee: ian at airs dot com
          Reporter: law at redhat dot com
                CC: ccoutant at google dot com

$ cat t.c
#include <stdio.h>
#include <dlfcn.h>

void foo(void) __attribute__((visibility("hidden")));
void foo(void) {
  puts("In executable: foo - before forwarding to DSO");
  ((void(*)(void))dlsym(RTLD_DEFAULT,"foo"))();
  puts("In executable: foo - after forwarding to DSO");
}

void bar(void);

int main() {
  foo();
  bar();
}

$ cat u.c
#include <stdio.h>

void foo(void);
void bar(void) {
  puts("In DSO: bar");
  foo();
}

$ cat v.c
#include <stdio.h>

void foo(void) {
  puts("In DSO: foo");
}


$ gcc v.c -fPIC -shared -olibv.so
$ gcc u.c -fPIC -shared -olibu.so
$ gcc -D_GNU_SOURCE t.c -L. -lu -lv -ldl -Wl,-rpath,`pwd`


When linking with the bfd linker, there is no error or warning.  However,
linking with gold produces:

/usr/bin/ld: warning: hidden symbol 'foo' in /tmp/ccAF4VIi.o is referenced by
DSO ./libu.so


Note we have two definitions of "foo".  One with default visibilty in libv and
one that is hidden (main executable) and a reference to foo with default
visibility (libu). 


>From the ELF standard:

---
 None of the visibility attributes affects resolution of symbols within an
executable or shared object during link-editing -- such resolution is
controlled by the binding type. Once the link-editor has chosen its resolution,
these attributes impose two requirements, both based on the fact that
references in the code being linked may have been optimized to take advantage
of the attributes.

    * First, all of the non-default visibility attributes, when applied to a
symbol reference, imply that a definition to satisfy that reference must be
provided within the current executable or shared object. If such a symbol
reference has no definition within the component being linked, then the
reference must have STB_WEAK binding and is resolved to zero.

    * Second, if any reference to or definition of a name is a symbol with a
non-default visibility attribute, the visibility attribute must be propagated
to the resolving symbol in the linked object. If different visibility
attributes are specified for distinct references to or definitions of a symbol,
the most constraining visibility attribute must be propagated to the resolving
symbol in the linked object. The attributes, ordered from least to most
constraining, are: STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.
---

Note carefully that visibility attributes do not affect symbol resolution
(which is controlled by the binding type).  Based on that wording I believe the
warning from gold is unnecessary and confusing.

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