[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: ia64 dodgy stack
From:       Jeff Johnston <jjohnstn () redhat ! com>
Date:       2005-02-24 18:28:12
Message-ID: 421E1CBC.40102 () redhat ! com
[Download RAW message or body]

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.

> 

[prev in list] [next in list] [prev in thread] [next in thread]