From: Bernd Geiser <desasterman@gmx.de>
To: gdb@sources.redhat.com
Subject: step into function fails
Date: Tue, 24 Jun 2003 08:16:00 -0000 [thread overview]
Message-ID: <200306241005.09959.desasterman@gmx.de> (raw)
I experienced it is not possible to step into functions of an executable
with stabs-debug-info. Only "stepi" seems to help! A little research
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 = find_pc_line (ecs->stop_func_start, 0);
===> if (tmp_sal.line != 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
MIPS-target, but also the ARM-target fails, when compiling with -gstabs). The
host is x86.
"objdump -G" proves the presence of line-number infomation. However, it is
NOT generated for the respective function's start-address, but for a later
address (after the prologue?):
----------- the (really simple :-) ) prog: --------------
int main()
{
int a;
a = 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
generated (the dwarf-format for the ARM works).
Is this a known issue or did anyone experience sth. similar?
Bernd
next reply other threads:[~2003-06-24 8:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 8:16 Bernd Geiser [this message]
2003-06-24 14:47 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200306241005.09959.desasterman@gmx.de \
--to=desasterman@gmx.de \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).