From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23852 invoked by alias); 27 Feb 2004 15:23:35 -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 23843 invoked from network); 27 Feb 2004 15:23:34 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 27 Feb 2004 15:23:34 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C640D2B92; Fri, 27 Feb 2004 10:23:29 -0500 (EST) Message-ID: <403F60F1.7020902@gnu.org> Date: Fri, 27 Feb 2004 15:23:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Joel Brobecker Cc: Elena Zannoni , gdb-patches@sources.redhat.com 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> In-Reply-To: <20040207040049.GH18961@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00803.txt.bz2 >>> > + 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? > > > Hmmm, good question... > > Although it does fix regression #2, it is not the only reason why we > added this test. It was also based on logic (see "After ... here is > what we found", in my previous message). > > I should admit that in the case at hand (regression #2), the unwinder > is having a hard time unwinding out of this code, and causes the > frame ID check to fail. I don't remember seeing several levels of > function call. > > However, I still thought that this test was necessary because we could > just as well have reached this trampoline one or more levels of function > call down, just as we end up stepping into undebuggable code in > regression #1. I'd not noticed this issue. Hmm, if GDB's single stepping then the second test should cover this case. It's when GDB is free running that we might find ourselves stopped IN_SOLIB_CALL_TRAMPOLINE. If it is the latter case then I'm not sure that silently single stepping away from where the program stopped is being helpful. Can you try the testsuite without that check? If the results are ok then (with other changes) commit it. If its not we need to re-think whats happening :-( Yes, this will mean it goes into 6.1. Andrew