From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9292 invoked by alias); 1 Mar 2004 19:48:02 -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 9230 invoked from network); 1 Mar 2004 19:48:00 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 1 Mar 2004 19:48:00 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 82FC247D62; Mon, 1 Mar 2004 11:48:01 -0800 (PST) Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping Message-ID: <20040301194801.GK1051@gnat.com> References: <20040205044119.GC18961@gnat.com> <20040205171324.GF18961@gnat.com> <16418.37058.65446.669052@localhost.redhat.com> <20040207040049.GH18961@gnat.com> <403F60F1.7020902@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403F60F1.7020902@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-03/txt/msg00011.txt.bz2 > >>> > + 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. 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. I did rerun the testsuite without it to double-check that my recollection was right. And I also ran the testsuite with the frame_id patch you recently posted, hoping that it might solve the extra regression. Unfortunately, I am sorry to report that it actually introduced another 5 or 6 regressions... On the other hand, as soon as I add the check back, we're down to zero regression (that is, with your frame_id patch as well). More details later today about the failing test when the test above is removed. -- Joel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9292 invoked by alias); 1 Mar 2004 19:48:02 -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 9230 invoked from network); 1 Mar 2004 19:48:00 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 1 Mar 2004 19:48:00 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 82FC247D62; Mon, 1 Mar 2004 11:48:01 -0800 (PST) Date: Mon, 01 Mar 2004 19:48:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping Message-ID: <20040301194801.GK1051@gnat.com> References: <20040205044119.GC18961@gnat.com> <20040205171324.GF18961@gnat.com> <16418.37058.65446.669052@localhost.redhat.com> <20040207040049.GH18961@gnat.com> <403F60F1.7020902@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403F60F1.7020902@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-03.o/txt/msg00011.txt Message-ID: <20040301194800.Ak4cCpObOB875FvqatEZczw_ucHmCZLDaF6NRZNv7iw@z> > >>> > + 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. 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. I did rerun the testsuite without it to double-check that my recollection was right. And I also ran the testsuite with the frame_id patch you recently posted, hoping that it might solve the extra regression. Unfortunately, I am sorry to report that it actually introduced another 5 or 6 regressions... On the other hand, as soon as I add the check back, we're down to zero regression (that is, with your frame_id patch as well). More details later today about the failing test when the test above is removed. -- Joel