From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8053 invoked by alias); 7 Oct 2004 16:48:58 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 8040 invoked from network); 7 Oct 2004 16:48:56 -0000 Received: from unknown (HELO smtp-out6.blueyonder.co.uk) (195.188.213.9) by sourceware.org with SMTP; 7 Oct 2004 16:48:56 -0000 Received: from amd64.cownie.net ([82.46.100.111]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 17:49:20 +0100 Received: from etnus.com (localhost [127.0.0.1]) by amd64.cownie.net (Postfix) with ESMTP id 41C831DA3E for ; Thu, 7 Oct 2004 17:48:55 +0100 (BST) To: binutils@sources.redhat.com Subject: Re: [rfa] Add bfd_runtime Reply-To: James Cownie Date: Thu, 07 Oct 2004 16:48:00 -0000 From: James Cownie Message-Id: <20041007164855.41C831DA3E@amd64.cownie.net> X-OriginalArrivalTime: 07 Oct 2004 16:49:21.0032 (UTC) FILETIME=[97CC2080:01C4AC8D] X-SW-Source: 2004-10/txt/msg00086.txt.bz2 This whole thing seems the wrong way to solve the fundamental problem to me. As I understand it the root problem is that the kernel and the dynamic linker are pretending to have linked a file into the image, but the pretence is incomplete. If the kernel (or maybe even the installation) were to make the contents of the vDSO available as a file (either by providing it in /sys, or /proc, or simply by having some code which ran at boot time which copied the vDSO out and saved it somewhere well known), then 1) The dynamic linker could fill in a perfectly normal rmap entry for the vDSO. 2) Any clients (such as gdb) which depend on the rmap entries could simply read the file like any other shared object. 3) There'd be no need for magic BFDs 4) The code to implement this would be less than has already been written to handle the fact that it's missing, and, probably less than the new code which is being proposed. The main problems I see with this approach are 1) It cuts across separate projects (so it needs either kernel or distribution work and some in libc). 2) For kernels which use multiple vDSOs in a single running kernel instance there will need to be a way of obtaining the appropriate vDSO. It's relatively simple to write a piece of code to extract the vDSO from its own address space and write it to a file, so if such a userspace program could be run at some point in the boot process no kernel changes would be needed, and the issues are reduced to choices of file names and so on (which, of course, are harder than writing code ;-( -- -- Jim -- James Cownie Etnus, LLC. +44 117 9071438 http://www.etnus.com