From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17459 invoked by alias); 2 Mar 2004 22:07:24 -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 17451 invoked from network); 2 Mar 2004 22:07:22 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (209.53.16.71) by sources.redhat.com with SMTP; 2 Mar 2004 22:07:22 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5619F47D62; Tue, 2 Mar 2004 14:07:22 -0800 (PST) Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: kettenis@gnu.org, Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping Message-ID: <20040302220722.GB715@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> <20040301194801.GK1051@gnat.com> <20040301235239.GP1051@gnat.com> <20040302061642.GW1051@gnat.com> <4044ACBF.1020302@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4044ACBF.1020302@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-03/txt/msg00031.txt.bz2 > 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? -- Joel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17459 invoked by alias); 2 Mar 2004 22:07:24 -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 17451 invoked from network); 2 Mar 2004 22:07:22 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (209.53.16.71) by sources.redhat.com with SMTP; 2 Mar 2004 22:07:22 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5619F47D62; Tue, 2 Mar 2004 14:07:22 -0800 (PST) Date: Tue, 02 Mar 2004 22:07:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: kettenis@gnu.org, Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping Message-ID: <20040302220722.GB715@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> <20040301194801.GK1051@gnat.com> <20040301235239.GP1051@gnat.com> <20040302061642.GW1051@gnat.com> <4044ACBF.1020302@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4044ACBF.1020302@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-03.o/txt/msg00031.txt Message-ID: <20040302220700.qeKx36u33l6Je8Fan7KuQIDO3Yp68q7jvpBXlLxQ9rY@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? -- Joel