From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14708 invoked by alias); 6 Feb 2002 00:39:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14632 invoked from network); 6 Feb 2002 00:39:07 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 6 Feb 2002 00:39:07 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C0AAF3E57; Tue, 5 Feb 2002 19:39:05 -0500 (EST) Message-ID: <3C607B29.7060306@cygnus.com> Date: Tue, 05 Feb 2002 16:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Blandy Cc: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: RFA: Do solib address arithmetic with appropriate truncation References: <20020203013131.C26295E9DE@zwingli.cygnus.com> <3C5D755D.4030201@cygnus.com> <1020204161424.ZM16473@localhost.localdomain> <3C5EBE78.1020500@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00144.txt.bz2 > Andrew Cagney writes: > >> > There must be something around that this code can use. On something > >> >> like a mips, this would be wrong - remember the sign extension problem. > >> > I've never really understood the MIPS sign extension problem. Does >> > it >> > occur when TARGET_PTR_BIT is smaller than the size of one or more of >> > the registers used to hold addresses? > >> >> >> The MIPS ISA when running 32 bit code, sign extends pointers. GDB >> mimics this behavour. If it encounters a 32 bit pointer it will >> convert it to/from a cannonical form (sign extended CORE_ADDR for >> MIPS). Such pointers occure everywhere - debug info, registers, >> memory, ... By always sign extending, GDB avoids any potential >> inconsistency and latent bugs. POINTER_TO_ADDRESS and >> ADDRESS_TO_POINTER handle this. >> >> When debugging MIPS, the first thing to check is that CORE_ADDRs are >> sign exteded. A value like ``0x80001234'' as the patch would >> generate, indicate a bug. >> >> Interestingly, the SPARC is showing signs of the same, or similar, problems. > > > Let me get this straight. From reading the .so file's section header > table, I'm going to get 64-bit offsets, right? And from reading the > dynamic linker's table of loaded shared libraries, I'm going to get > 32-bit offsets, right? A 32 or 64 bit section header? > So, if I have a .so section which says its offset is 0xf0000000, and > the dynamic linker's table says that the .so has been loaded at an > offset of 0x20000000, should I determine that the address at which the > section was actually loaded is 0x110000000, or 0x10000000? Assuming 64 bit section header and 32 bit offset (TARGET_PTR_BIT == 64). 0xf0000000 -> 0xfffffffff0000000 0x20000000 -> 0x0000000020000000 -------------------------------- 0x0000000010000000 Assuming a 32 bit MIPS section header and offset (TARGET_PTR_BIT == 32 and address<->pointer is signed): 0xf0000000 0x20000000 ---------- 0x10000000 -> 0x0000000010000000 > Or, if the section's offset is 0x70000000, and the dynamic linker says > the .so is loaded at an offset of 0x20000000, do I get a section address > of 0xffffffff90000000, or 0x0000000090000000? > > Spell it out for me, baby. :) Assuming 64 bit section header and 32 bit offset: 0x70000000 -> 0x0000000070000000 0x20000000 -> 0x0000000020000000 -------------------------------- 0x0000000090000000 Assuming a 32 bit MIPS section header and offset: 0x70000000 0x20000000 ---------- 0x90000000 -> 0xffffffff90000000 Andrew