From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15431 invoked by alias); 22 Jan 2012 18:59:24 -0000 Received: (qmail 15422 invoked by uid 22791); 22 Jan 2012 18:59:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.synsport.com (HELO shepard.synsport.net) (208.69.230.148) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Jan 2012 18:59:06 +0000 Received: from [192.168.0.11] (atoulouse-256-1-15-210.w90-38.abo.wanadoo.fr [90.38.98.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id A61A943B4A; Sun, 22 Jan 2012 12:59:04 -0600 (CST) Message-ID: <4F1C5C72.8010905@marino.st> Date: Sun, 22 Jan 2012 18:59:00 -0000 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: binutils@sourceware.org, Ian Lance Taylor 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> In-Reply-To: <4F0753A4.7000507@marino.st> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00229.txt.bz2 On 1/6/2012 9:03 PM, John Marino wrote: > On 1/6/2012 3:42 PM, Ian Lance Taylor wrote: >> John Marino writes: >> >>> On 1/5/2012 7:31 PM, Ian Lance Taylor wrote: >>>>> 2. ver_matching_test.sh: __bss_start not local, rtld issue? real issue? (failed on v2.21 too) >>>> >>>> Hard to understand why this would fail. The __bss_start symbol is >>>> defined automatically by the linker itself. >>> >>> ok. I thought I remembered seeing references to __bss_start in rtld >>> code, so I suspected rtld was the culprit. >> >> 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? >>>>> 4. intpri2: likely real problem. gdb log attached >>>> >>>> This is almost certainly the same issue as the --no-ctors-in-init-array >>>> issue: DragonFly does not suppor DT_INIT_ARRAY. >>> >>> If I wanted to add DT_INIT_ARRAY support to DragonFly, what component >>> needs to be updated? again rtld? >> >> Yes. Also you need to do some magic for statically linked executables, >> taking advantage of the linker-defined symbols __init_array_start and >> __init_array_end and friends. I started working to support this. It also requires new code for crt1 to handle the main executable. It's going to take some more work to implement this completely. >>>>> 5. relro_test: no relro support in rtld, ignore >>>>> 6. relro_now_test: no relro support in rtld, ignore >>>>> 7. relro_strip_test: no relro support in rtld, ignore >>>> >>>> Yeah, if the dynamic linker does not handle relro, then these tests are >>>> expected to fail. >>> >>> As far as I can tell, no BSD supports relro and it seems to be of >>> limited value so I don't suspect this will change any time soon. >> >> I'm surprised that no BSD supports relro as it is a security >> enhancement. I agree that the value is limited but it is not zero. >> >> In my opinion, the biggest advantage is for the PLT. The PLT must often >> be writable when the program starts, so that dynamic relocations can be >> applied. The PLT holds code addresses, so this gives various sorts of >> overflow attacks a way to change which code will execute, by overwriting >> the PLT. >> >> The point of relro is that after all the PLT relocations have been >> applied, there is no need for the PLT to change again. Making the PLT >> be relro implements that: the dynamic linker applies the relocations, >> then uses mprotect to make the PLT readonly. >> >> This does of course require that the PLT be fully relocated at program >> startup time, rather than using lazy PLT relocations which is the >> default behaviour. You can use the linker option -z now to request that >> all PLT relocations be fully relocated at program startup, and when gold >> sees -z now it will make the PLT a relro section. >> >> Ian 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. John