From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 454 invoked by alias); 14 Feb 2006 00:56:43 -0000 Received: (qmail 421 invoked by uid 22791); 14 Feb 2006 00:56:42 -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; Tue, 14 Feb 2006 00:56:40 +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 k1E0ub1K016392 for ; Mon, 13 Feb 2006 19:56:37 -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 k1E0uW109199 for ; Mon, 13 Feb 2006 19:56:32 -0500 Received: from localhost.localdomain (vpn50-96.rdu.redhat.com [172.16.50.96]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k1E0uWvb032070 for ; Mon, 13 Feb 2006 19:56:32 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id k1E0vQkK002591 for ; Mon, 13 Feb 2006 17:57:26 -0700 Date: Tue, 14 Feb 2006 00:56:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: cope with varying prelink base addresses Message-ID: <20060213175637.4ac50484@ironwood.lan> In-Reply-To: References: <200602082139.k18LdXig008477@elgar.sibelius.xs4all.nl> <20060210014235.GB8310@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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/msg00294.txt.bz2 On Mon, 13 Feb 2006 17:03:30 -0200 Alexandre Oliva wrote: > 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. I agree. (I've been careful to not let in any patches which would support alternate l_addr semantics.) I've been looking over your patch and would like to see it committed so long as it receives a some more testing first. Would it be possible for you to test it on Solaris system and a BSD system? Kevin