[RFA] Fix an unwinding problem on alpha-tru64

[Joel Brobecker <brobecker@gnat.com>]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

Hello,

One of our users reported that GDB is unable to compute the backtrace
from __hstTransferRegistersPC on Tru64 5.1b. We never noticed this before
because our machines run 4.0f and 5.1a.

Anyway, what happened is that the user switched to an inactive thread,
and then asked for the backtrace, and got:

    (gdb) bt
    #0  0x000003ff805c174c in __hstTransferRegistersPC () 
        from /usr/shlib/libpthread.so
    #1  0x000003ff805b0fe8 in __osTransferContext ()
        from /usr/shlib/libpthread.so
    warning: Hit heuristic-fence-post without finding
    warning: enclosing function for address 0x20000a1d440

And inspection of the assembly code for __osTransferContext reveals
the source of the problem:

        Dump of assembler code for function __osTransferContext:
        <__osTransferContext>:    ldah    gp,16321(t12)
        <__osTransferContext+4>:  unop
        <__osTransferContext+8>:  lda     gp,-3056(gp)
        <__osTransferContext+12>: unop
        <__osTransferContext+16>: lda     sp,-64(sp)
        <__osTransferContext+20>: stq     ra,0(sp)
        <__osTransferContext+24>: stq     s0,8(sp)
        <__osTransferContext+28>: stq     s1,16(sp)
        <__osTransferContext+32>: stq     s2,24(sp)
        <__osTransferContext+36>: stq     s3,32(sp)
        <__osTransferContext+40>: stq     s4,40(sp)
        <__osTransferContext+44>: stq     fp,48(sp)
        <__osTransferContext+48>: mov     sp,fp
        [...]
        <__osTransferContext+160>:        ldq     ra,0(s2)
        <__osTransferContext+164>:        stq     ra,8(sp)

So we can see that the return address is saved at $fp+0 (insn @ +20
and +48). The function scanner in alpha_heuristic_frame_unwind_cache()
first interpreted the code correctly and stored the fact that $ra
was at $fp+0. However, upon reading the insn @ +164, it doesn't realizes
that it's the second time we see this register being saved, and therefore
changes our record of the register save location to $fp+8. This causes
us to fetch the wrong value for the return address, and then leads to
the heuristic-fence-post warning.

2004-03-31  Joel Brobecker  <brobecker@gnat.com>

        * alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Do not take
        into account an instruction saving a register if we have already
        seen an earlier instruction saving that same register.

Tested on alpha-tru64 5.1a, no regression.
OK to apply?

Thanks,
-- 
Joel

[-- Attachment #2: alpha-tdep.c.diff --]
[-- Type: text/plain, Size: 991 bytes --]

Index: alpha-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/alpha-tdep.c,v
retrieving revision 1.128
diff -u -p -r1.128 alpha-tdep.c
--- alpha-tdep.c	23 Mar 2004 14:47:54 -0000	1.128
+++ alpha-tdep.c	31 Mar 2004 23:58:36 -0000
@@ -1029,6 +1029,16 @@ alpha_heuristic_frame_unwind_cache (stru
 	    {
 	      reg = (word & 0x03e00000) >> 21;
 
+              /* Ignore this instruction if we have already encountered
+                 an instruction saving the same register earlier in the
+                 function code.  The current instruction does not tell
+                 us where the original value upon function entry is saved.
+                 All it says is that the function we are scanning reused
+                 that register for some computation of its own, and is now
+                 saving its result.  */
+              if (info->saved_regs[reg])
+                continue;
+
 	      if (reg == 31)
 		continue;