This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] mips 32/64 register/stack fix
- From: Michael Snyder <msnyder at redhat dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com, cagney <cagney at redhat dot com>, Daniel Jacobowitz <drow at mvista dot com>
- Date: Thu, 22 Apr 2004 21:43:44 +0000
- Subject: Re: [RFA] mips 32/64 register/stack fix
- Organization: Red Hat, Inc.
- References: <408813A9.6000402@redhat.com> <4088242A.4070601@gnu.org>
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 <do_frame_unwind_register>, 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.