From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19063 invoked by alias); 6 Jan 2012 14:43:11 -0000 Received: (qmail 19054 invoked by uid 22791); 6 Jan 2012 14:43:09 -0000 X-SWARE-Spam-Status: No, hits=-2.5 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; Fri, 06 Jan 2012 14:42:54 +0000 Received: by iacb35 with SMTP id b35so3227988iac.0 for ; Fri, 06 Jan 2012 06:42:53 -0800 (PST) Received: by 10.43.117.194 with SMTP id fn2mr6084048icc.53.1325860973605; Fri, 06 Jan 2012 06:42:53 -0800 (PST) Received: by 10.43.117.194 with SMTP id fn2mr6084036icc.53.1325860973432; Fri, 06 Jan 2012 06:42:53 -0800 (PST) Received: from coign.google.com ([67.218.110.43]) by mx.google.com with ESMTPS id z22sm214518493ibg.5.2012.01.06.06.42.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 06:42:52 -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> Date: Fri, 06 Jan 2012 14:43:00 -0000 In-Reply-To: <4F06CBE0.6080109@marino.st> (John Marino's message of "Fri, 06 Jan 2012 11:24:32 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 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/msg00111.txt.bz2 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. >>> 3. exception_static_test: likely real problem. gdb log attached >> >> My first guess would be that DragonFly does not support dl_iterate_phdr, >> or that it does not work correctly for statically linked executables. >> That's just a guess, though. > > I brought in dl_iterate_phdr support to dragonfly (system compiler is > 4.4.7 snapshot, 2011-10-25), and it appears to be working although > maybe in the case of statically linked executables it's not. What > handles the latter? Is that an rtld thing? Statically linked executables don't use rtld at all. They need to use a completely different mechanism to get the program segments, typically just the single set associated with the executable itself. On GNU/Linux systems the kernel passes the program segments in the auxiliary vector using AT_PHDR and AT_PHNUM, and the startup code saves those for use by dl_iterate_phdr in a static executable. >>> 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. >>> 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