From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16290 invoked by alias); 5 Feb 2002 23:30:19 -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 16176 invoked from network); 5 Feb 2002 23:30:11 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 5 Feb 2002 23:30:11 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id B63565E9DE; Tue, 5 Feb 2002 18:31:45 -0500 (EST) To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Do solib address arithmetic with appropriate truncation References: <20020203013131.C26295E9DE@zwingli.cygnus.com> <1020203180114.ZM12779@localhost.localdomain> From: Jim Blandy Date: Tue, 05 Feb 2002 15:30:00 -0000 In-Reply-To: <1020203180114.ZM12779@localhost.localdomain> 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/msg00138.txt.bz2 Kevin Buettner writes: > On Feb 2, 8:31pm, Jim Blandy wrote: > > > Sat Feb 2 17:03:26 2002 Jim Blandy > > > > * solib-svr4.c (svr4_truncate_ptr): New function. > > (svr4_relocate_section_addresses): Do the address arithmetic with > > the appropriate truncation for target addresses, even when > > CORE_ADDR is larger than a target address. > > I think this is a satisfactory short term (or even mid term) solution. > I think the long term solution will be to introduce a method for adding > offsets to CORE_ADDRs. See > > http://sources.redhat.com/ml/gdb/2001-10/msg00036.html > > I think it's okay to commit this patch, but I'd appreciate it if you'd > add a comment indicating that svr4_truncate_ptr() should be removed > when methods for adding displacements to CORE_ADDRs are introduced. Okay, I've committed it with the following comment: /* Clear any bits of ADDR that wouldn't fit in a target-format data pointer. "Data pointer" here refers to whatever sort of address the dynamic linker uses to manage its sections. At the moment, we don't support shared libraries on any processors where code and data pointers are different sizes. This isn't really the right solution. What we really need here is a way to do arithmetic on CORE_ADDR values that respects the natural pointer/address correspondence. (For example, on the MIPS, converting a 32-bit pointer to a 64-bit CORE_ADDR requires you to sign-extend the value. There, simply truncating the bits above TARGET_PTR_BIT, as we do below, is no good.) This should probably be a new gdbarch method or something. */