From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3252 invoked by alias); 22 Apr 2004 21:43:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3244 invoked from network); 22 Apr 2004 21:43:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 Apr 2004 21:43:50 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3MLhnKG017167 for ; Thu, 22 Apr 2004 17:43:49 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3MLhjw10753; Thu, 22 Apr 2004 17:43:46 -0400 Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i3MLhjC02110; Thu, 22 Apr 2004 14:43:45 -0700 Message-ID: <40883C90.7030509@redhat.com> Date: Thu, 22 Apr 2004 21:43:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.2) Gecko/20040301 MIME-Version: 1.0 To: Andrew Cagney CC: gdb-patches@sources.redhat.com, cagney , Daniel Jacobowitz Subject: Re: [RFA] mips 32/64 register/stack fix References: <408813A9.6000402@redhat.com> <4088242A.4070601@gnu.org> In-Reply-To: <4088242A.4070601@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: 0 X-SW-Source: 2004-04/txt/msg00547.txt.bz2 Andrew Cagney wrote: >> ! if (mips_saved_regsize (tdep) < mips_regsize (gdbarch) && >> ! trad_frame_addr_p (info->saved_regs, regnum)) >> ! { > > > This doesn't look right, can you post a backtrace? Yep. Here's the context. Target string = mipsisa64-elf. Host i6860pc-linux-gnu. The test case is gdb.base/return.c, the multilib parameter is "-mips32", and the testsuite generated this compiler command: /home/msnyder/gnupro/builds/cross/mipsisa64/gcc/xgcc -B/home/msnyder/gnupro/builds/cross/mipsisa64/gcc/ /home/msnyder/gnupro/gnupro-cross/gdb/testsuite/gdb.base/return.c -I/home/msnyder/gnupro/builds/cross/mipsisa64/mipsisa64-elf/mips32/newlib/targ-include -I/home/msnyder/gnupro/gnupro-cross/newlib/libc/include -B/home/msnyder/gnupro/builds/cross/mipsisa64/mipsisa64-elf/mips32/libgloss/mips/ -L/home/msnyder/gnupro/builds/cross/mipsisa64/mipsisa64-elf/mips32/libgloss/mips -L/home/msnyder/gnupro/gnupro-cross/libgloss/mips -L/home/msnyder/gnupro/builds/cross/mipsisa64/ld -B/home/msnyder/gnupro/builds/cross/mipsisa64/mipsisa64-elf/mips32/newlib/ -L/home/msnyder/gnupro/builds/cross/mipsisa64/mipsisa64-elf/mips32/newlib -g -lm -Tidt64.ld -mips32 -o /home/msnyder/gnupro/builds/cross/mipsisa64/gdb/testsuite/gdb.base/return The sequence of commands that gets the mips64-gdb into trouble are taken from the return.exp testcase: (gdb) target sim (gdb) load (gdb) break func1 (gdb) run (gdb) return Now, return_command calls frame_pop which calls regcache_save, which eventually calls mips_mdebug_frame_prev_register with a regnum that is saved on the stack. Here's the partial backtrace at that point: #0 mips_mdebug_frame_prev_register (next_frame=0x83e7408, this_cache=0x83e747c, regnum=120, optimizedp=0xbfffc2d4, lvalp=0xbfffc2c0, addrp=0xbfffc2c8, realnump=0xbfffc2c4, valuep=0xbfffc320) at /home/msnyder/gnupro/gnupro-cross/gdb/mips-tdep.c:1687 #1 0x0818d806 in frame_register_unwind (frame=0x83e746c, regnum=120, optimizedp=0xbfffc2d4, lvalp=0xbfffc2c0, addrp=0xbfffc2c8, realnump=0xbfffc2c4, bufferp=0xbfffc320) at /home/msnyder/gnupro/gnupro-cross/gdb/frame.c:547 #2 0x0818db61 in frame_unwind_register (frame=0x83e746c, regnum=120, buf=0xbfffc320) at /home/msnyder/gnupro/gnupro-cross/gdb/frame.c:626 #3 0x0818d60f in do_frame_unwind_register (src=0x83e746c, regnum=120, buf=0xbfffc320) at /home/msnyder/gnupro/gnupro-cross/gdb/frame.c:458 #4 0x080e3f46 in regcache_save (dst=0x846a650, cooked_read=0x818d5f8 , src=0x83e746c) at /home/msnyder/gnupro/gnupro-cross/gdb/regcache.c:386 #5 0x0818d67f in frame_pop (this_frame=0x83e746c) at /home/msnyder/gnupro/gnupro-cross/gdb/frame.c:484 #6 0x0812012d in return_command (retval_exp=0x0, from_tty=1) at /home/msnyder/gnupro/gnupro-cross/gdb/stack.c:1922 #7 0x080bd10b in do_cfunc (c=0x83e1568, args=0x0, from_tty=1) at /home/msnyder/gnupro/gnupro-cross/gdb/cli/cli-decode.c:57 #8 0x080bf0c9 in cmd_func (cmd=0x83e1568, args=0x0, from_tty=1) at /home/msnyder/gnupro/gnupro-cross/gdb/cli/cli-decode.c:1541 Register 120 is the first one that's saved on the stack (ie. trad_frame_addr_p is true). So now we call trad_frame_prev_register, which calls get_frame_memory, passing it a size which it gets from calling register_size(gdbarch, regnum), which looks like this: #0 register_size (gdbarch=0x84093e8, regnum=120) at /home/msnyder/gnupro/gnupro-cross/gdb/regcache.c:281 281 size = descr->sizeof_register[regnum]; Well regcache->descr->sizeof_register [120] is 8, but by looking at the saved_registers structure, you can see that the addresses where they are saved are only 4 bytes apart. So we read 8 bytes when we should read 4 bytes, and eventually the value comes back shifted left by 4 bytes in its buffer. Therefore when we allow the return command to complete, we get: (gdb) return^M Make func1 return now? (y or n) y^M #0 0x8002032400000000 in ?? ()^M (gdb) FAIL: gdb.base/return.exp: simple return Where the address shown should have been 0xffffffff80020324. This causes at least 500 FAILs per multi-lib, all of which go away with my patch. I'm guessing they all have to do with return, finish, or target function calls.