From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7105 invoked by alias); 25 Mar 2004 14:42:33 -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 7051 invoked from network); 25 Mar 2004 14:42:29 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 25 Mar 2004 14:42:29 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 00E7D2B92; Thu, 25 Mar 2004 09:42:26 -0500 (EST) Message-ID: <4062EFD2.7000308@gnu.org> Date: Thu, 25 Mar 2004 14:42: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: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: Signal Trampoline Frames References: <200403242303.i2ON33uL005973@elgar.kettenis.dyndns.org> <40622721.6010603@gnu.org> <200403251026.i2PAQXRr000635@elgar.kettenis.dyndns.org> In-Reply-To: <200403251026.i2PAQXRr000635@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00614.txt.bz2 > > and uses > > the arbitrary number 8 for the number of instructions (which makes it > > not quite suitable for SPARC). > > I'm assuming people will increase it (It's like the arbitrary number 16 > for the largest possible size of an instruction). > > OK. Although you must realize that for SPARC we might need to > increase it to 80 or so. Then it makes more sense to check only for a > small number of key instructions I think. In that case, don't use it. BTW, what happens if the inferior is interrupted while executing one of those 80 instructions? > > The whole thing seems a bit > > over-engineered to me :-(. > > In what way? > > I wrote it after churn out 4 almost identical signal trampolines - so it > works for one type but not for others. You also haven't seen my test > cases :-) > > My experience is that there is too much variation for a > one-size-fits-all trampoline recognition function. I was under the > impression that there were only two cases where this could be used. > Turns out I'm wrong. I still think we run the risk of > over-engineering this by adding to much knobs if we try to make it > work for too many slightly different signal tramps. Right. It's a helper for a specific, but fairly common, case. It works for me (and appears to work for daniel :-) but is definitly not a one size fits all. Andrew