This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ia64 dodgy stack


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]