From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ac131313@cygnus.com>
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Received: (qmail 26403 invoked from network); 3 Feb 2002 18:24:38 -0000
Received: from unknown (HELO localhost.redhat.com) (216.138.202.10)
  by sources.redhat.com with SMTP; 3 Feb 2002 18:24:38 -0000
Received: from cygnus.com (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id 1E4E03E4D; Sun,  3 Feb 2002 12:37:34 -0500 (EST)
Message-ID: <3C5D755D.4030201@cygnus.com>
Date: Sun, 03 Feb 2002 10:24:00 -0000
From: Andrew Cagney <ac131313@cygnus.com>
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 <jimb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Do solib address arithmetic with appropriate truncation
References: <20020203013131.C26295E9DE@zwingli.cygnus.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-02/txt/msg00038.txt.bz2

> + /* 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.

Andrew