From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24829 invoked by alias); 24 Feb 2005 18:28:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24771 invoked from network); 24 Feb 2005 18:28:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Feb 2005 18:28:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1OISEvW020832 for ; Thu, 24 Feb 2005 13:28:19 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1OISDK16781; Thu, 24 Feb 2005 13:28:13 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j1OISD7l016828; Thu, 24 Feb 2005 13:28:13 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 01692800001; Thu, 24 Feb 2005 13:28:12 -0500 (EST) Message-ID: <421E1CBC.40102@redhat.com> Date: Fri, 25 Feb 2005 05:36:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: David Lecomber Cc: gdb Subject: Re: ia64 dodgy stack References: <1109264963.23124.24.camel@delmo.priv.wark.uk.streamline-computing.com> In-Reply-To: <1109264963.23124.24.camel@delmo.priv.wark.uk.streamline-computing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00158.txt.bz2 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 : [MII] alloc r33=ar.pfs,4,4,0 > 0x4000000000002e81 : adds r12=-176,r12 > 0x4000000000002e82 : mov r34=r32;; > 0x4000000000002e90 : [MMI] adds r35=128,r12;; > 0x4000000000002e91 : st8 [r35]=r34 > 0x4000000000002e92 : adds r12=176,r12 > > and the section around the call to def is: > > 0x4000000000002f20 : [MMI] adds r20=144,r12;; > 0x4000000000002f21 : ld8 r34=[r20] > 0x4000000000002f22 : nop.i 0x0;; > 0x4000000000002f30 : [MII] mov r1=r34 > 0x4000000000002f31 : adds r35=128,r12 > 0x4000000000002f32 : nop.i 0x0;; > 0x4000000000002f40 : [MIB] mov r36=r35 > 0x4000000000002f41 : nop.i 0x0 > 0x4000000000002f42 : br.call.sptk.many > b0=0x4000000000002e80 ;; > 0x4000000000002f50 : [MMI] mov r34=1;; > 0x4000000000002f51 : nop.m 0x0 > 0x4000000000002f52 : 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. >