From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15857 invoked by alias); 18 Feb 2010 13:53:57 -0000 Received: (qmail 15843 invoked by uid 22791); 18 Feb 2010 13:53:56 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 13:53:51 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1IDro6R005330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Feb 2010 08:53:50 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1IDrjNn003641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Feb 2010 08:53:48 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o1IDriUi011839 for ; Thu, 18 Feb 2010 14:53:44 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o1IDrhNa011838 for gdb@sourceware.org; Thu, 18 Feb 2010 14:53:43 +0100 Date: Thu, 18 Feb 2010 13:53:00 -0000 From: Jan Kratochvil To: gdb@sourceware.org Subject: Re: CORE_ADDR representation Message-ID: <20100218135342.GA11674@host0.dyn.jankratochvil.net> References: <20100218044416.GA19485@caradoc.them.org> <20100218103404.GA1597@host0.dyn.jankratochvil.net> <20100218134137.GA17163@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100218134137.GA17163@caradoc.them.org> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00125.txt.bz2 On Thu, 18 Feb 2010 14:41:41 +0100, Daniel Jacobowitz wrote: > On Thu, Feb 18, 2010 at 11:34:04AM +0100, Jan Kratochvil wrote: > > these "& mask" parts can be removed. This masking was there already before > > start of the PIE(+OSX) patches. > > I don't understand. How can the masking possibly be removed? If you > don't mask, 0x50000000 + 0x40000000 == 0x90000000 and that's not going > to work on MIPS where we need 0xffffffff90000000. OK, my mistake. (You wrote somewhere MIPS32 uses only lower 2GB, expected higher 2GB is used for some special purposes when you care about it and those lower and higher 2GB do not mix.) > This won't show the same problem, you'll need to use mips-elf instead. > MIPS Linux places application code below 0x80000000 exclusively; MIPS > ELF (at least some versions) starts applications in KSEG0, at > 0x80000000. OK, that explains those "lower 2GB" on MIPS32. There can be CORE_ADDR-as-address which would be always zero-extended and CORE_ADDR-as-displacement which would be always sign-extended. Having them as scalar types will not sanity check the code is right during compilation but it would not need replacing all CORE_ADDR '+'/'-'es by functions calls as in: http://sourceware.org/ml/gdb-patches/2010-02/msg00415.html (the 200KB patch with addr_add_offset&.co.) Thanks, Jan