From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13176 invoked by alias); 26 Jan 2004 18:25:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13168 invoked from network); 26 Jan 2004 18:25:36 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 26 Jan 2004 18:25:37 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 824022B8F; Mon, 26 Jan 2004 13:25:35 -0500 (EST) Message-ID: <40155B9F.2010205@gnu.org> Date: Mon, 26 Jan 2004 18:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: MIPS saved register troubles References: <20040126155623.GA2979@nevyn.them.org> <4015493C.4010805@gnu.org> <20040126171415.GA4860@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00306.txt.bz2 > On Mon, Jan 26, 2004 at 12:07:08PM -0500, Andrew Cagney wrote: > >> >I spent some time fiddling with backtraces in an o32 application, using a >> >mips64-linux GDB, this morning. They don't work so well :) The basic >> >problem is the [0,NUM_REGS) hack. mips_register_raw_size reports that >> >register $28 is 8 bytes wide, so legacy_saved_regs_prev_register loads two >> >consecutive saved values into $28, and it looks like 0x7ffffe007ffffd8c >> >($s8 >> >concatenated with $sp). > >> >> Can you provide more details? > > > Sure. It turns out I was mistaken about [0,NUM_REGS) being directly > the problem - we were actually unwinding in [NUM_REGS, NUM_REGS * 2). Ah, that explains why I wasn't so sure. > What happens is that legacy_saved_regs_prev_register copies > REGISTER_RAW_SIZE(regno) bytes from memory into the register cache. > When debugging an o32 binary with a mips64-configured GDB, > REGISTER_RAW_SIZE(90 + 28) is 8. But a normal o32 stack frame pushes 4 > bytes per register. So the eight-byte copy gets this saved register > and the next one also. If o32 on mips64, register 28 should be 8-bytes and register num_regs+28 should be 4-bytes. The latter being what the unwind code plays with. What does a backtrace look like? >> >Fixing this is going to be ugly. Andrew, I don't suppose you have a plan >> >to >> >migrate MIPS to the new frame code, thereby making all this go away? > >> >> I'm not so sure? BTW, you can't miss my irregular MIPS cleanups. My >> current problem is: >> [regression] Internal error: pc 0x400b21 in read in psymtab, but not in >> symtab. >> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1519 >> look familar? > > > Not at all. Pertinent missing detail - does this show up with HEAD? > Or is HEAD broken for some other reason? That's how I found the bug :-) > I don't have an IRIX system but I can probably get a sense of the > problem on mips64-linux. I'll take a look this week. Per the bug report, can be reproduced using mips-elf-gdb. I get the feeling that original patch should have modified the callers so that they supplied the section rather than have the function locally guess the section. For MIPS, it's finding but then [incorrectly] discarding a valid absolute symbol. Andrew