ia64 dodgy stack

ia64 dodgy stack

[David Lecomber]

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>

Re: ia64 dodgy stack

[Jeff Johnston]

David Lecomber wrote:
> 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?
>

Do you have libunwind installed and if so, what version?  The newer ia64 
debugger uses libunwind for stack unwinding.  It is possible that the compiler 
is not generating proper libunwind info.  Try specifying:

   set debug arch 1

as you enter gdb.  If libunwind is being used, you will see mention of 
ia64_find_proc_info_x.  If libunwind is having problems with the info, you can 
reconfigure gdb with --without-libunwind and that will fall back to the old 
prologue analysis code.

-- Jeff J.

>