ia64 dodgy stack

[David Lecomber <david@streamline-computing.com>]

I have a stacktrace problem with some, ahem,.. Fortran code.. (intel
compiler 8) on the Itanium and current CVS of GDB.  The problem did not
exist on GDB 5.2.2 - this got the answer perfectly..

The code for this is included (should anyone wish to compile it.)

The issue is that the stacktrace just fails: shows the current stack and
then it's 0x00000000

(gdb) b def
Breakpoint 1 at 0x4000000000002e92: file myyuck.f90, line 8.
(gdb) r
Starting program: /home/david/a.out
 
Breakpoint 1, def (a=31.3402061) at myyuck.f90:8
8             END
Current language:  auto; currently fortran
(gdb) bt
#0  def (a=31.3402061) at /home/david/myyuck.f90:8
#1  0x0000000000000000 in ?? ()

The code:

      SUBROUTINE DEF(A)
      REAL :: A
 
      END
 
      PROGRAM ABC
      REAL A
      CALL DEF(A)
      END
 

The function def's disassembly is:

0x4000000000002e80 <def+0>:     [MII]       alloc r33=ar.pfs,4,4,0
0x4000000000002e81 <def+1>:                 adds r12=-176,r12
0x4000000000002e82 <def+2>:                 mov r34=r32;;
0x4000000000002e90 <def+16>:    [MMI]       adds r35=128,r12;;
0x4000000000002e91 <def+17>:                st8 [r35]=r34
0x4000000000002e92 <def+18>:                adds r12=176,r12

and the section around the call to def is:

0x4000000000002f20 <abc+96>:    [MMI]       adds r20=144,r12;;
0x4000000000002f21 <abc+97>:                ld8 r34=[r20]
0x4000000000002f22 <abc+98>:                nop.i 0x0;;
0x4000000000002f30 <abc+112>:   [MII]       mov r1=r34
0x4000000000002f31 <abc+113>:               adds r35=128,r12
0x4000000000002f32 <abc+114>:               nop.i 0x0;;
0x4000000000002f40 <abc+128>:   [MIB]       mov r36=r35
0x4000000000002f41 <abc+129>:               nop.i 0x0
0x4000000000002f42 <abc+130>:               br.call.sptk.many
b0=0x4000000000002e80 <def>;;
0x4000000000002f50 <abc+144>:   [MMI]       mov r34=1;;
0x4000000000002f51 <abc+145>:               nop.m 0x0
0x4000000000002f52 <abc+146>:               mov b0=r33;;


Any advice?


-- 
David Lecomber <david@lecomber.net>
-- 
David Lecomber <david@streamline-computing.com>