From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10628 invoked by alias); 14 Aug 2007 20:20:44 -0000 Received: (qmail 10515 invoked by uid 22791); 14 Aug 2007 20:20:43 -0000 X-Spam-Check-By: sourceware.org Received: from el-out-1112.google.com (HELO el-out-1112.google.com) (209.85.162.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Aug 2007 20:20:36 +0000 Received: by el-out-1112.google.com with SMTP id r27so364244ele for ; Tue, 14 Aug 2007 13:20:35 -0700 (PDT) Received: by 10.90.105.19 with SMTP id d19mr8799609agc.1187122834645; Tue, 14 Aug 2007 13:20:34 -0700 (PDT) Received: by 10.100.127.9 with HTTP; Tue, 14 Aug 2007 13:20:34 -0700 (PDT) Message-ID: Date: Tue, 14 Aug 2007 20:20:00 -0000 From: "Vinod pandarinathan" To: "Paul Koning" Subject: Re: MIPS 64 bit addressing query Cc: gdb@sourceware.org In-Reply-To: <18103.27059.549214.117236@pkoning.equallogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070806015122.GA29212@caradoc.them.org> <18103.27059.549214.117236@pkoning.equallogic.com> 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: 2007-08/txt/msg00119.txt.bz2 Thanks everyone for the details. Its still difficult to figure out where the sign extension should happen. We have a mips64 target but run mips32 binaries on the target. The addresses are 32 bits in the executable file they are just loaded into the symbol table as 32 bit addresses. When the breakpoint is hit, symbol address from the symbol table is not sign extended (bpt->address) and compared to sign extended program counter which seems to cause the problem. Does the sign extension happen when the addresses are stored in the breakpoint structure in (set_raw_breakpoint) or even earlier when the symbols are read from the executable ? Thanks Vinod. On 8/6/07, Paul Koning wrote: > >>>>> "Vinod" == Vinod pandarinathan writes: > > Vinod> Hi, Thanks for the quick reply. I upgraded the debugger to > Vinod> gdb6.6 but still seeing the same problem. I searched the > Vinod> newsgroup and found a related thread > > Vinod> http://www.ecos.sourceware.org/ml/gdb/2006-10/msg00088.html > > Vinod> I checked mips-tdep.c where the function > Vinod> set_gdbarch_integer_to_address uses mips_integer_to_address > Vinod> which sign extends the 32 bit value. From the above thread it > Vinod> is suggested to use unsigned integer extension. However I am > Vinod> still trying to find where the zero extended > Vinod> address[bpt->address] is coming from. > > The ecos thread is for a different architecture, the SH. I don't know > about that one, but the MIPS rule is entirely clear -- 32-bit > addresses are sign extended, NOT zero extended, to make a 64-bit > address. So if you're seeing problems because of a zero-extended > address, the fix is to track down where that comes from and make it > sign-extend instead. > > paul > >