From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13529 invoked by alias); 24 Jun 2003 08:16:29 -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 17428 invoked from network); 24 Jun 2003 08:03:05 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by sources.redhat.com with SMTP; 24 Jun 2003 08:03:05 -0000 Received: (qmail 11109 invoked by uid 65534); 24 Jun 2003 08:03:03 -0000 Received: from unknown (EHLO grafenwalder) (194.176.3.129) by mail.gmx.net (mp006) with SMTP; 24 Jun 2003 10:03:03 +0200 Content-Type: text/plain; charset="us-ascii" From: Bernd Geiser To: gdb@sources.redhat.com Subject: step into function fails Date: Tue, 24 Jun 2003 08:16:00 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200306241005.09959.desasterman@gmx.de> X-SW-Source: 2003-06/txt/msg00468.txt.bz2 I experienced it is not possible to step into functions of an executable=20 with stabs-debug-info. Only "stepi" seems to help! A little research=20 showed that this test (in gdb/infrun.c) fails: /* If we have line number information for the function we are thinking of stepping into, step into it. If there are several symtabs at that PC (e.g. with include files), just want to know whether any of them have line numbers. find_pc_line handles this. */ { struct symtab_and_line tmp_sal; tmp_sal =3D find_pc_line (ecs->stop_func_start, 0); =3D=3D=3D> if (tmp_sal.line !=3D 0) { step_into_function (ecs); return; } } Consequently this one gets called: step_over_function (ecs); which is obviously wrong. I use gdb 5.3 and compiled the program with gcc 2.95.3 (both configured for= a=20 MIPS-target, but also the ARM-target fails, when compiling with -gstabs). T= he=20 host is x86. "objdump -G" proves the presence of line-number infomation. However, it is= =20 NOT generated for the respective function's start-address, but for a later= =20 address (after the prologue?): ----------- the (really simple :-) ) prog: -------------- int main() { int a; a =3D doppelt(2); return a+1; } int doppelt(int x) { return 2*x; } ------------ its object-dump ------------------- bash# objdump -G mips_exec mips: file format elf32-little Contents of .stab section: Symnum n_type n_othr n_desc n_value n_strx String [...] 22 SLINE 0 42 00000050 0 23 SLINE 0 43 00000058 0 24 SLINE 0 44 00000058 0 25 SLINE 0 45 00000068 0 26 SLINE 0 46 00000080 0 27 SLINE 0 46 00000080 0 28 FUN 0 42 00000040 716 main:F1 29 LSYM 0 43 fffffff0 724 a:1 30 LBRAC 0 0 00000058 0 31 RBRAC 0 0 00000080 0 32 FUN 0 0 00000058 0 33 SOL 0 0 00000040 1 a.c 34 SLINE 0 49 000000a4 0 35 SLINE 0 50 000000a8 0 36 SLINE 0 51 000000c4 0 37 FUN 0 49 00000098 728 doppelt:F1 38 PSYM 0 48 00000000 739 x:p1 39 FUN 0 0 00000040 0 ----------------------------------------------------------- This effect appears for a MIPS- as well as an ARM-target when stabs-info is= =20 generated (the dwarf-format for the ARM works). Is this a known issue or did anyone experience sth. similar?=20 Bernd