This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] use frame IDs to detect function calls while stepping
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: Elena Zannoni <ezannoni at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Mon, 1 Mar 2004 15:52:39 -0800
- Subject: Re: [RFA] use frame IDs to detect function calls while stepping
- References: <20040205044119.GC18961@gnat.com> <20040205171324.GF18961@gnat.com> <16418.37058.65446.669052@localhost.redhat.com> <20040207040049.GH18961@gnat.com> <403F60F1.7020902@gnu.org> <20040301194801.GK1051@gnat.com>
Ok, I'm dark red with shame.
> Yes, there is a regression (regression #2 in my previous message) if
> we leave that test out. It's been a while since I posted that patch,
> so I don't remember the details anymore :-/. I'll dig again later today.
It looks like my initial analysis of the cause of regression #2 was
wrong. I will simply say that I was mislead by the fact that GDB
reported that we stopped in "_PROCEDURE_LINKAGE_TABLE_" while we
were actually inside function "exit", and let it go at that.
Here is a description of the regression which appears if we don't
include the following test:
+ if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name))
+ {
+ /* We landed in a shared library call trampoline, so it
+ is a subroutine call. */
+ handle_step_into_function (ecs);
+ return;
+ }
The problem occurs with ending-run:
% gdb ending-run
(gdb) b ending-run.c:33
Breakpoint 1 at 0x10828: file gdb.base/ending-run.c, line 33.
(gdb) run
Starting program: /[...]/gdb.base/ending-run
-1 2 7 14 23 34 47 62 79 Goodbye!
Breakpoint 1, main () at gdb.base/ending-run.c:33
33 }
(gdb) n
0x000105ec in _start ()
(gdb) n
Single stepping until exit from function _start,
which has no line number information.
0x00020950 in _PROCEDURE_LINKAGE_TABLE_ ()
The expected behavior for the last "next" command is for GDB
to run until the inferior exits:
(gdb) n
Single stepping until exit from function _start,
which has no line number information.
Program exited normally.
Unfortunately, here is what happens. At 0x000105ec, before we do
our second "next" command, we are about to execute the following
code:
0x000105ec <_start+100>: call 0x20950 <exit>
0x000105f0 <_start+104>: nop
After two iterations (one for the call insn, and one for the delay
slot), GDB lands at the begining of function "exit" at 0x00020950,
which is:
0x00020950 <exit+0>: sethi %hi(0xf000), %g1
0x00020954 <exit+4>: b,a 0x20914 <_PROCEDURE_LINKAGE_TABLE_>
0x00020958 <exit+8>: nop
So at this point, the registers window has not been rotated.
I don't know if this is the cause for this problem, but at this
point GDB is unable to unwind the call stack:
(gdb) bt
#0 0x00020950 in _PROCEDURE_LINKAGE_TABLE_ ()
(And gets the wrong procedure name as well, but that's a separate
issue - although "x /i" does report what I believe is the correct
name, strange!).
I am looking into the sparc unwinder code right now, to try to
understand a bit better the source of the problem.
--
Joel