From owner-freebsd-current@FreeBSD.ORG Sun May 25 17:19:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7AEC37B401; Sun, 25 May 2003 17:19:25 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9083E43F3F; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q0JOwk045838; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h4Q0JOrv001357; Sun, 25 May 2003 17:19:24 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h4Q0JOcG001356; Sun, 25 May 2003 17:19:24 -0700 (PDT) Date: Sun, 25 May 2003 17:19:24 -0700 From: Marcel Moolenaar To: "Matthew N. Dodd" Message-ID: <20030526001924.GA1272@athlon.pn.xcllnt.net> References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030525190744.A86964@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030525190744.A86964@sasami.jurai.net> User-Agent: Mutt/1.5.4i cc: current@FreeBSD.ORG Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 00:19:26 -0000 On Sun, May 25, 2003 at 07:34:37PM -0400, Matthew N. Dodd wrote: > > > Interesting. However, it seems to me that prebinding is solving a > > problem it should not be solving. I would expect that the toolchain > > sanitizes the dependency list. Put differently, if I add a library to a > > link but none of the exported symbols are actually being referenced, > > then there's no dependency and the final shared object should not have > > that library recorded at all. The runtime overhead between a minimal > > link and a bloated link would then be minimal (there's always the chance > > of false positives). > > This doesn't seem to be the case, or if it is our rtld isn't taking > advantage of any toolchain hints. All relocations in a shared libraries > must be handled on the off chance that the program will dlopen() a shared > object. I'm not sure I understand what you mean. AFAICT, you only have to record dependencies if the shared objects are in the initial set of loadable objects (ie those that must be loaded at initial program load). It doesn't matter if the program itself loads additional shared objects. Also, I don't think dlopen() has any consequences for static linking. One does not have to provide libraries on the link line if they are only dlopen()'d. > > To explicitly state my standing on prebinding: I'm mostly un- convinced > > that it's something we need at this time. Patching the toolchain is > > considered a sin by me. Also, the footnote that it "only works for i386 > > for now" is getting annoying and to me only means that the testing > > results are too colored or biased to be useful. > > I'm not happy with having to patch the toolchain either. Do you know if the toolchain developers are working on this? > > o An OS specific segment type/name is expected to be prefixed by > > the os name to avoid collition. Thus: (type)PT_FREEBSD_BUILDID > > and (name)".freebsd.buildid". > > Maybe PT_BSD_BUILDID since it should be fairly easy to get this code > running on the other BSD systems. The EI_OSABI field in the ELF header (e_ident[]) defines the meaning of the OS specific extensions (in the same way the e_machine defines the CPU specific extension). Since ELFOSABI_NETBSD != ELFOSABI_FREEBSD != ELFOSABI_OPENBSD, we need to ensure that the segment type for prebinding is identical across the OSABIs if we want to share the name. It can be done, but I would not assume a priori that we'll succeed. I probably would stick to a FreeBSD specific name until there's complete buy-in. > > o The use of time and some random key is too adhoc and does not > > really provide the uniqueness one wants. Given that UUIDs have > > showed up in a lot of places not originally intended for UUIDs > > to show up, one might as well use UUIDs here. Make sure you > > nail down the byte order if you want to use UUIDs. > > I was more concerned with simplicity; the method I use solves the problem > with minimal effort and complexity. The combination of time() + random() > + filename will not collide on a single box. But it can across NFS, right? > > o The prebind cache file format is not sufficiently multi-platform > > I'll be adding a platform identifier to the file header. All I'm > concerned with is being able to reject a file if its not for the current > platform. I have no expectation of cross-generating prebinding files. Please keep that option open. Not only do we have to deal with byte- order on a single platform, we also have to keep an eye on emulation layers (ia32 on ia64 and ia32 on amd64). Decoupling the program from its prebinding information can create all sorts of nasty (ie unexpected) complexities. > > Have you thought about updating the executable itself? > > Of course. I eliminated all the wrong/impossible methods of implementing > prebinding. Having the prebinding cache file added as an ELF section was > one of the first things I tried. :) What are the major reasons for not editing the executable in your opinion? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net