From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94723 invoked by alias); 5 May 2015 15:54:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 94680 invoked by uid 48); 5 May 2015 15:54:44 -0000 From: "thiago at kde dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic Date: Tue, 05 May 2015 15:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.1.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: thiago at kde dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-05/txt/msg00380.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #31 from Thiago Macieira --- (In reply to Jakub Jelinek from comment #29) > You are missing the point of copy relocations. Consider: > int a = 1; > extern int b, c; > int foo (void) > { > return a + b + c; > } > compiled with -fno-pic or -fpie. a is known to be defined in the > executable, but b and c are externals. Without copy relocations you'd need > to emit significantly slower code (extra .got reference or similar) for all > the accesses to the externals, with copy relocations you can optimistically > assume they will likely be defined in the executable (usual case for larger > programs, at least for C shared libraries people avoid exporting variables > from shared libraries if easily possible), and if not, the linker will > create copy relocations. That is true. But if you place the same code in a library, then now all accesses must be indirect, even for a. My assertion isn't about the usefulness of copy relocations, it's that they are optimising for the wrong thing. The size and complexity of libraries and plugins in desktop applications is orders of magnitude above that of the application codebases. > Only with whole program (LTO or similar) compilation, when you can talk to > the linker, you could find out if the externals from some TU are defined > within the executable or not. Or if we tag them appropriately. int a = 1; extern int b; __attribute__((dllimport)) extern int c; int foo(void) { return a + b + c; } Now the compiler knows that a is in the local executable and it can assume that b is too, but it also knows that c isn't and must be accessed indirectly. This did not require LTO. Modern libraries already all have a macro preceding all the function and variable declarations meant to be used by other DSOs, ever since Ulrich Drepper's "dso-howto" manual. The macro tags are required so that we have a proper __attribute__((visibility("default"))) when the library is compiled with -fvisibility=hidden. Moreover, the same tag expands to __declspec(dllexport) or __declspec(dllimport) on Windows if the library is cross-platform. So the precedent is there and modern libraries are mostly ready to make use of the feature.