From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-12460-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 7068 invoked by alias); 4 Feb 2002 16:15:08 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 6910 invoked from network); 4 Feb 2002 16:15:01 -0000
Received: from unknown (HELO cygnus.com) (205.180.230.5)
  by sources.redhat.com with SMTP; 4 Feb 2002 16:15:01 -0000
Received: from cse.cygnus.com (cse.sfbay.redhat.com [205.180.230.236])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA04406;
	Mon, 4 Feb 2002 08:14:57 -0800 (PST)
Received: (from kev@localhost)
	by cse.cygnus.com (8.11.6/8.11.6) id g14GEPf16474;
	Mon, 4 Feb 2002 09:14:25 -0700
Date: Mon, 04 Feb 2002 08:15:00 -0000
From: Kevin Buettner <kevinb@redhat.com>
Message-Id: <1020204161424.ZM16473@localhost.localdomain>
In-Reply-To: Andrew Cagney <ac131313@cygnus.com>
        "Re: RFA: Do solib address arithmetic with appropriate truncation" (Feb  3, 12:37pm)
References: <20020203013131.C26295E9DE@zwingli.cygnus.com> 
	<3C5D755D.4030201@cygnus.com>
X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera)
To: Andrew Cagney <ac131313@cygnus.com>, Jim Blandy <jimb@cygnus.com>
Subject: Re: RFA: Do solib address arithmetic with appropriate truncation
Cc: gdb-patches@sources.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-02/txt/msg00075.txt.bz2

On Feb 3, 12:37pm, Andrew Cagney wrote:

> > + /* 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.  */
> > + static CORE_ADDR
> > + svr4_truncate_ptr (CORE_ADDR addr)
> > + {
> > +   if (TARGET_PTR_BIT == sizeof (CORE_ADDR) * 8)
> > +     /* We don't need to truncate anything, and the bit twiddling below
> > +        will fail due to overflow problems.  */
> > +     return addr;
> > +   else
> > +     return addr & (((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1);
> > + }
> 
> 
> 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?

Kevin