From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27896 invoked by alias); 10 Feb 2006 01:42:39 -0000 Received: (qmail 27888 invoked by uid 22791); 10 Feb 2006 01:42:38 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 10 Feb 2006 01:42:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F7NIx-0002DJ-7t; Thu, 09 Feb 2006 20:42:35 -0500 Date: Fri, 10 Feb 2006 01:42:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva Cc: Mark Kettenis , gdb-patches@sources.redhat.com, cagney@redhat.com Subject: Re: cope with varying prelink base addresses Message-ID: <20060210014235.GB8310@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , Mark Kettenis , gdb-patches@sources.redhat.com, cagney@redhat.com References: <200602082139.k18LdXig008477@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00232.txt.bz2 On Thu, Feb 09, 2006 at 10:08:47PM -0200, Alexandre Oliva wrote: > > 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. No, Alexandre, Mark is talking about something that we actually experienced. The interpretations are _not_ the same when the base address in the program header is non-zero. There was at least one dynamic loader which set l_addr to the absolute address the segment was loaded to, even though the program header's l_addr was non-zero. I believe that this was, at varying times, MIPS Linux and MIPS NetBSD. At least one of the loaders was later changed to avoid the problem, and I'm not sure what happened to the other. The linker was also updated. -- Daniel Jacobowitz CodeSourcery