From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17899 invoked by alias); 6 Mar 2004 00:15:30 -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 17892 invoked from network); 6 Mar 2004 00:15:30 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 6 Mar 2004 00:15:30 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1B0162B92; Fri, 5 Mar 2004 19:15:25 -0500 (EST) Message-ID: <4049181C.7020904@gnu.org> Date: Sat, 06 Mar 2004 00:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Joel Brobecker Cc: kettenis@gnu.org, 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> <403F60F1.7020902@gnu.org> <20040301194801.GK1051@gnat.com> <20040301235239.GP1051@gnat.com> <20040302061642.GW1051@gnat.com> <4044ACBF.1020302@gnu.org> <20040302220722.GB715@gnat.com> In-Reply-To: <20040302220722.GB715@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00121.txt >>How about this as a compromize: >>> >>> - in 6.1 >>> your original patch (but with a comment saying that the >>> + if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)) >>> is a hack and shouldn't be included in the mainline) >>> >>> - in mainline: >>> Assuming Mark's ok with the sparc changes, your patch without that part? >>> >>> This way 6.1 is robust regardless of which SPARC architecture code is in >>> place. > > > it looks reasonable, but it'd be nice to have Mark's opinion on the > unwinder problem. How about we let it sit for another day or two before > we commit anything? > > Also, do we need this change in 6.1? It seemed like a pretty minor bug > that I managed to produce on Tru64 only. Or were there other occurrences > of this bug? So mainline only it is .... (For safety, I was testing my frame unwinders with this applied). Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17899 invoked by alias); 6 Mar 2004 00:15:30 -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 17892 invoked from network); 6 Mar 2004 00:15:30 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 6 Mar 2004 00:15:30 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1B0162B92; Fri, 5 Mar 2004 19:15:25 -0500 (EST) Message-ID: <4049181C.7020904@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Joel Brobecker Cc: kettenis@gnu.org, 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> <403F60F1.7020902@gnu.org> <20040301194801.GK1051@gnat.com> <20040301235239.GP1051@gnat.com> <20040302061642.GW1051@gnat.com> <4044ACBF.1020302@gnu.org> <20040302220722.GB715@gnat.com> In-Reply-To: <20040302220722.GB715@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00121.txt.bz2 Message-ID: <20040319000900.v_XX9ke7PlfXhZeNl1QQxOkIwzFk26x6dCvzUlnhr3Y@z> >>How about this as a compromize: >>> >>> - in 6.1 >>> your original patch (but with a comment saying that the >>> + if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)) >>> is a hack and shouldn't be included in the mainline) >>> >>> - in mainline: >>> Assuming Mark's ok with the sparc changes, your patch without that part? >>> >>> This way 6.1 is robust regardless of which SPARC architecture code is in >>> place. > > > it looks reasonable, but it'd be nice to have Mark's opinion on the > unwinder problem. How about we let it sit for another day or two before > we commit anything? > > Also, do we need this change in 6.1? It seemed like a pretty minor bug > that I managed to produce on Tru64 only. Or were there other occurrences > of this bug? So mainline only it is .... (For safety, I was testing my frame unwinders with this applied). Andrew