Re: [RFA] mips 32/64 register/stack fix

[Michael Snyder <msnyder at redhat dot com>]

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.