From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19898-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 16380 invoked by alias); 15 Oct 2004 13:42:17 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 16355 invoked from network); 15 Oct 2004 13:42:15 -0000
Received: from unknown (HELO localhost.localdomain) (80.6.110.86)
  by sourceware.org with SMTP; 15 Oct 2004 13:42:15 -0000
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i9FDnKgN027229
	for <gdb@sources.redhat.com>; Fri, 15 Oct 2004 14:49:20 +0100
Subject: i386 prologue
From: David Lecomber <david@streamline-computing.com>
To: gdb@sources.redhat.com
Content-Type: text/plain
Message-Id: <1097848160.1773.91.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Fri, 15 Oct 2004 15:25:00 -0000
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-10/txt/msg00325.txt.bz2

My knowledge of this area is very limited, but I regularly come across
bad stack traces in GDB, and I think the problem is in i386-tdep.c 
i386_analyze_frame_setup

The code there seems very specific to GNU compilers, expecting either an
"enter" - or a pushl %ebp.  Well, here's what you get from Intel version
7.1 fortran compiler:

Dump of assembler code for function test:
0x0804afd0 <test+0>:    push   %ebx
0x0804afd1 <test+1>:    mov    %esp,%ebx
0x0804afd3 <test+3>:    and    $0xfffffff0,%esp
0x0804afd6 <test+6>:    push   %edi
0x0804afd7 <test+7>:    push   %esi
0x0804afd8 <test+8>:    push   %ebp
0x0804afd9 <test+9>:    sub    $0x74,%esp
0x0804afdc <test+12>:   movl   $0x81d34ac,0x81ad07c
0x0804afe6 <test+22>:   movl   $0x81d34a0,0x81ad088
0x0804aff0 <test+32>:   push   $0x81ad06c
0x0804aff5 <test+37>:   push   $0x4
0x0804aff7 <test+39>:   call   0x816ca94 <f_iof>
0x0804affc <test+44>:   push   $0x81ad098
0x0804b001 <test+49>:   push   $0x0
0x0804b003 <test+51>:   call   0x81698b0 <f_ioc>
0x0804b008 <test+56>:   add    $0x10,%esp
0x0804b00b <test+59>:   test   %eax,%eax

and even:
0x080b71c8 <kpl_minput+0>:      push   %ebp
0x080b71c9 <kpl_minput+1>:      push   %ebx
0x080b71ca <kpl_minput+2>:      sub    $0x34,%esp
0x080b71cd <kpl_minput+5>:      mov    0x40(%esp),%ebx
0x080b71d1 <kpl_minput+9>:      mov    (%ebx),%edx
0x080b71d3 <kpl_minput+11>:     movl   $0xffffffff,0x81e4588
0x080b71dd <kpl_minput+21>:     test   %edx,%edx
0x080b71df <kpl_minput+23>:     jle    0x80b7d51 <kpl_minput+2953>
0x080b71e5 <kpl_minput+29>:     mov    0x84711b0,%eax
0x080b71ea <kpl_minput+34>:     movl   $0xd52,0x81e458c
0x080b71f4 <kpl_minput+44>:     movl   $0xffffffff,0x81e4590
0x080b71fe <kpl_minput+54>:     mov    0xfffffffc(%eax,%edx,4),%eax
0x080b7202 <kpl_minput+58>:     cmp    $0xfffffffe,%eax
0x080b7205 <kpl_minput+61>:     je     0x80b7d2f <kpl_minput+2919>


This seriously upsets things.. the stack becomes absolutely useless!!

Is there some alternative -- does libunwind offer a solution?  Or is the
prologue stuff the Right Thing To Do [TM]?

Anyone have any ideas?

d.