From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19173 invoked by alias); 22 Jan 2012 19:43:27 -0000 Received: (qmail 19160 invoked by uid 22791); 22 Jan 2012 19:43:26 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Jan 2012 19:43:13 +0000 Received: by iadj38 with SMTP id j38so4598796iad.0 for ; Sun, 22 Jan 2012 11:43:12 -0800 (PST) Received: by 10.42.144.69 with SMTP id a5mr5507037icv.45.1327261392492; Sun, 22 Jan 2012 11:43:12 -0800 (PST) Received: by 10.42.144.69 with SMTP id a5mr5507027icv.45.1327261392373; Sun, 22 Jan 2012 11:43:12 -0800 (PST) Received: from coign.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net. [71.133.8.30]) by mx.google.com with ESMTPS id r18sm38025287ibh.4.2012.01.22.11.43.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 Jan 2012 11:43:11 -0800 (PST) From: Ian Lance Taylor To: John Marino Cc: binutils@sourceware.org Subject: Re: gold linker 2.22 regressed for DragonFly [revised testsuite results] References: <4ED7FCA6.8090706@marino.st> <4ED88FA5.8050408@marino.st> <4EFF3AF3.3080404@marino.st> <4F017A8B.1000905@marino.st> <4F0204FA.2090305@marino.st> <4F0209E5.4000709@marino.st> <4F0235FE.5050702@marino.st> <4F02C833.2060309@marino.st> <4F06CBE0.6080109@marino.st> <4F0753A4.7000507@marino.st> <4F1C5C72.8010905@marino.st> Date: Sun, 22 Jan 2012 19:43:00 -0000 In-Reply-To: <4F1C5C72.8010905@marino.st> (John Marino's message of "Sun, 22 Jan 2012 19:58:58 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQmWmRtO1x3ML8Heo2w0Ye3k1d+5rbmZJXUdWfDazSFIuILeDICYeI6RDE/OLM1pyNmyE1XZvbRxA8XIBxhD9XQ/Bqfj6391vlmvIx0iFY0lmB2o8jhm5pEZ0jECCdh96mGHiDaasppFQam+b/vkkXqg3tgdYafN1KeogVdBcQhCQZ4m+AM= Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00230.txt.bz2 John Marino writes: >>> Ideally rtld should not have a publically visible definition of >>> __bss_start, but I don't see how it would cause a test failure even if >>> it did. > > > After many hours of digging into the issue, I might have an > explanation for why the __bss_start and _edata symbols are getting > assigned to the dynamic symbol table. This is the only test that > FreeBSD passes and DragonFly doesn't, and the reason for that wasn't > clear. > > Finally using --trace-symbol=__bss_start might have provided a clue. > It said __bss_start was defined in libc.so, libm.so, and libstdc++.so. > My guess is that the presence of the symbols in those libraries caused > gold to promote the __bss_start symbol to global. > > As for why FreeBSD doesn't have these symbols in their system > libraries, the difference might be in their use of symbol version > maps. Unfortunately DragonFly doesn't yet version their library > functions, so the lack of version scripts means every library has this > symbol. > > Am I on the right track in diagnosing this test failure? Sounds like it. There may be a target independent problem here. What should the linker do if the version script specifies that a symbol is local but the symbol is also defined in a shared library? I think it has to make the symbol local despite the definitions, but it sounds like that is not happening. > I came up with an initial implementation of relro for the dynamic > linker and FreeBSD's Konstantin Belousov reviewed and added to it. > Now DragonFly passes these three tests and I think there's a good > chance that code will get incorporated into FreeBSD as well. Cool. Ian