From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22809 invoked by alias); 6 Feb 2002 00:07:03 -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 22702 invoked from network); 6 Feb 2002 00:07:00 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 6 Feb 2002 00:07:00 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id E821A5E9DE; Tue, 5 Feb 2002 19:08:34 -0500 (EST) To: Andrew Cagney 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> From: Jim Blandy Date: Tue, 05 Feb 2002 16:07:00 -0000 In-Reply-To: <3C5EBE78.1020500@cygnus.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00142.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? 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? 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. :)