From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80856 invoked by alias); 5 May 2015 15:47:08 -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 80587 invoked by uid 48); 5 May 2015 15:47:05 -0000 From: "jakub at gcc dot gnu.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:47: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: jakub at gcc dot gnu.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/msg00377.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 --- Comment #29 from Jakub Jelinek --- (In reply to Thiago Macieira from comment #27) > Still, if this were solved properly, relocations that resolved back into the > executable itself would still be bound locally, even position-dependently if > that's how the binary were built. I am asking that it stop doing copy > relocations, which only applies to symbols the linker *did* detect came from > elsewhere. 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. 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.