From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25590 invoked by alias); 5 Feb 2004 18:54:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25579 invoked from network); 5 Feb 2004 18:54:47 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Feb 2004 18:54:47 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 47FAE1A4412; Thu, 5 Feb 2004 13:51:46 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.37058.65446.669052@localhost.redhat.com> Date: Thu, 05 Feb 2004 18:54:00 -0000 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping In-Reply-To: <20040205171324.GF18961@gnat.com> References: <20040205044119.GC18961@gnat.com> <20040205171324.GF18961@gnat.com> X-SW-Source: 2004-02/txt/msg00101.txt.bz2 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. */