From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5912 invoked by alias); 10 Feb 2006 00:09:00 -0000 Received: (qmail 5900 invoked by uid 22791); 10 Feb 2006 00:09:00 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 00:08:58 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1A08uRl027731 for ; Thu, 9 Feb 2006 19:08:56 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1A08u108926; Thu, 9 Feb 2006 19:08:56 -0500 Received: from livre.oliva.athome.lsd.ic.unicamp.br (vpn50-42.rdu.redhat.com [172.16.50.42]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k1A08tOb008143; Thu, 9 Feb 2006 19:08:55 -0500 Received: from livre.oliva.athome.lsd.ic.unicamp.br (livre.oliva.athome.lsd.ic.unicamp.br [127.0.0.1]) by livre.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5) with ESMTP id k1A08rxw019919; Thu, 9 Feb 2006 22:08:53 -0200 Received: (from aoliva@localhost) by livre.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5/Submit) id k1A08ndb019917; Thu, 9 Feb 2006 22:08:49 -0200 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, cagney@redhat.com Subject: Re: cope with varying prelink base addresses References: <200602082139.k18LdXig008477@elgar.sibelius.xs4all.nl> From: Alexandre Oliva Date: Fri, 10 Feb 2006 00:09:00 -0000 In-Reply-To: <200602082139.k18LdXig008477@elgar.sibelius.xs4all.nl> (Mark Kettenis's message of "Wed, 8 Feb 2006 22:39:33 +0100 (CET)") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00228.txt.bz2 On Feb 8, 2006, Mark Kettenis wrote: > This code is very fragile, and defenitely should be tested on more > than a single platform. Seriously, what's fragile about it? Only if we meet a certain set of conditions that are only likely to hold in the case of prelinking are we going to get any change in behavior, and I don't see anything fragile about the set of conditions. Sure enough it might not work on all OSs, but where it does not, it won't make any difference whatsoever. > In the past, we've seen that not every OS > interprets the l_addr field of `struct link_map'. I don't change in any way the way l_addr is handled. What I do is apply an offset atop of l_addr if the conditions are met, where the conditions are designed to ensure that, if you are to apply it, you'll be bringing in a definite improvement, rather than perhaps making things worse. > And MIPS targets > have a history of doing things differently even for the same OS. > Basically the two interpretations are: > a. l_addr is the absolute address at which the shared object is loaded. > b. l_addr is the relative address used to relocate the shared object. Actually, both interpretations are the same. It looks one or the other because of the base addresses that appear in the program headers. In general, dynamic libraries start at address zero, but when they're prelinked, they don't, and then l_addr may remain as zero to reflect that no additional offset was applied. > The word "heuristic" makes me a bit nervous. It seems to me that the > dynamic linker should be able to provide the necessary information. I don't see how, without duplicating phdr information in read-write segments, degrading performance and memory use at run time for the unlikely benefit of a debugger in case of a core dump. Core files won't contain copies of phdrs or any other read-only segments, so we can't compare them with what's in the binary to tell whether we have a match, and comparing modifyable data, that is in the core file, is unlikely to work, since the data may have been modified. The only piece of information available to aid the decision is the dynamic table address. If the binary changes in any way and you try to use a core file referencing the other binary, all bets are off already. This will just try to increase the odds of proper functioning in case the only change to the binary was a change in its base load address, something that prelink and the dynamic loader will cooperate to do. > Perhaps you should raise the issue with the glibc developers, to see > what they can do? It doesn't make sense for glibc to do anything about this. We already have all the information we need, at least as far as glibc is concerned. My worry is about other platforms that might represent a different a different piece of information in l_ld. For those, we just won't get a match, and everything will proceed just like it did before, which I've carefully designed the code to do. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}