From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33847 invoked by alias); 27 Mar 2015 05:58:08 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 33835 invoked by uid 89); 27 Mar 2015 05:58:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.2 X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 27 Mar 2015 05:58:06 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb] Relax PR 15228 protected visibility restriction From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Message-Id: Date: Fri, 27 Mar 2015 06:53:00 -0000 X-SW-Source: 2015-q1/txt/msg06882.txt.bz2 *** TEST RESULTS FOR COMMIT b84171287ffe60dd1e7c02262a0493862fa21a97 *** Author: Alan Modra Branch: master Commit: b84171287ffe60dd1e7c02262a0493862fa21a97 Relax PR 15228 protected visibility restriction Allows .dynbss copy of shared library protected visibility variables if they are read-only. To recap: Copying a variable from a shared library into an executable's .dynbss is an old hack invented for non-PIC executables, to avoid the text relocations you'd otherwise need to access a shared library variable. This works with ELF shared libraries because global symbols can be overridden. The trouble is that protected visibility symbols can't be overridden. A shared library will continue to access it's own protected visibility variable while the executable accesses a copy. If either the shared library or the executable updates the value then the copy diverges from the original. This is wrong since there is only one definition of the variable in the application. So I made the linker report an error on attempting to copy protected visibility variables into .dynbss. However, you'll notice the above paragraph contains an "If". An application that does not modify the variable value remains correct even though two copies of the variable exist. The linker can detect this situation if the variable was defined in a read-only section. PR ld/15228 PR ld/18167 * elflink.c (elf_merge_st_other): Add "sec" parameter. Don't set protected_def when symbol section is read-only. Adjust all calls. * elf-bfd.h (struct elf_link_hash_entry): Update protected_def comment.