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: Elena Zannoni <ezannoni at redhat dot com>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 Feb 2004 13:51:46 -0500
- Subject: Re: [RFA] use frame IDs to detect function calls while stepping
- References: <20040205044119.GC18961@gnat.com><20040205171324.GF18961@gnat.com>
Joel Brobecker writes:
> [aghaaaaa .... With the patch this time, with my thanks to Elena and Daniel]
>
> 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.
>
Could this kind of logic be handled inside handle_step_into_function
(which already checks for UNDEBUGGABLE)? I.e. is this case caught by
the complex condition in the old frame case which makes you call
handle_step_into_function? For the new frame case, this is regression
#1, did you have this bug/regression with the old frame code?
> . 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.
>
I think the explanations above should go in the function as comments.
> + else
> + {
> + 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;
> + }
I am not sure I understand why the case above is not covered by the
test below. Is this to fix regression #1? I.e multiple frames?
> +
> + if (frame_id_eq (get_frame_id (get_prev_frame (get_current_frame ())),
> + step_frame_id))
> + {
> + /* It's a subroutine call. */
> + handle_step_into_function (ecs);
> + return;
> + }
> +
> }
>
> /* We've wandered out of the step range. */