This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFA] use frame IDs to detect function calls while stepping
- From: Joel Brobecker <brobecker at gnat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 Feb 2004 08:41:19 +0400
- Subject: [RFA] use frame IDs to detect function calls while stepping
Hello,
This is a followup on the discussion that took place in the following
thread:
[RFA] OSF/1 - "next" over prologueless function call
http://sources.redhat.com/ml/gdb-patches/2003-12/msg00037.html
During the discussion, it appeared that it was better to rely on
frame IDs to detect cases when we stepped inside a function rather
than further adjusting the test that checks whether we landed at
the begining of a function or not.
After a bit of testing on various platforms, I found that only relying
on a test that checks the ID of frame #1 against the step_frame_id was
not sufficient, unfortunately. The sparc-solaris testing revealed 2
regressions.
After careful analysis of the regressions and a bit of dicussion
with Andrew, here is what we found:
1. We sometimes step levels of function calls down from the point
where we started stepping. This is to get past the dynsym
resolve code. So once we get more than one level deep, the
frame ID test can no longer work.
That was regression #1.
2. We have a testcase where we try to "next" our way out of a function
for which we have no line number information. The expected output
was to run until the end of the program. But instead we stopped
before.
It turned out that we were landing inside a shared library
trampoline after having left the function we were in, so again
the frame ID check didn't kick in. We didn't know what to do,
simply stopped there.
That was regression #2.
Given the current implementation, and the analysis of the regressions,
we determined that the logic should be something like this:
. If we landed in undebuggable code (identified by lack of symbol
name), and we're stepping over this kind of code, then:
Run our way out of the function.
. If we are in a shlib call trampoline, then:
Likewise.
(This test was already part of the previous check, BTW)
. If we are in a function called from the function where we started
stepping, as identified by frame ID unwind, then:
Likewise.
I tried it and no longer had any regression.
2004-02-05 J. Brobecker <brobecker@gnat.com>
* infrun.c (handle_inferior_event): Rewrite the checks detecting
cases when we stepped inside a function.
Tested on alpha-tru64, pa-hpux, sparc-solaris and x86-linux.
And it also fixes the problem I originally reported.
OK to apply?
Thanks,
--
Joel