From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9569 invoked by alias); 13 Feb 2006 19:03:37 -0000 Received: (qmail 9560 invoked by uid 22791); 13 Feb 2006 19:03:36 -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; Mon, 13 Feb 2006 19:03:34 +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 k1DJ3WgQ012453 for ; Mon, 13 Feb 2006 14:03:32 -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 k1DJ3W112217; Mon, 13 Feb 2006 14:03:32 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (vpn50-33.rdu.redhat.com [172.16.50.33]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k1DJ3VBi026351; Mon, 13 Feb 2006 14:03:31 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (free.oliva.athome.lsd.ic.unicamp.br [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5) with ESMTP id k1DJ3U96031162; Mon, 13 Feb 2006 17:03:30 -0200 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.13.5/8.13.5/Submit) id k1DJ3U7u031160; Mon, 13 Feb 2006 17:03:30 -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> <20060210014235.GB8310@nevyn.them.org> From: Alexandre Oliva Date: Mon, 13 Feb 2006 19:03:00 -0000 In-Reply-To: <20060210014235.GB8310@nevyn.them.org> (Daniel Jacobowitz's message of "Thu, 9 Feb 2006 20:42:35 -0500") 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/msg00289.txt.bz2 On Feb 9, 2006, Daniel Jacobowitz wrote: > 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. Yuck. Fair enough. Anyhow, I don't see any evidence that GDB actually supports any such broken l_addr semantics, so it's not like the patch would be breaking anything. If anything, it would be enabling gdb to work on such a system work, assuming l_ld is set up correctly. -- 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}